Skip to content

fix(tasks): avoid dropping completed task results during collection #639

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
coinmoles wants to merge 1 commit into
base: main
Choose a base branch
from
+3 −3
Open

fix(tasks): avoid dropping completed task results during collection #639

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions crates/rmcp/src/task_manager.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,14 +195,13 @@ impl OperationProcessor {
}

/// Collect completed results from running tasks and remove them from the running tasks map.
pub fn collect_completed_results(&mut self) -> Vec<TaskResult> {
pub fn collect_completed_results(&mut self) {
Copy link
Collaborator

@alexhancock alexhancock Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thoughts on this being pub in the first place?

Copy link
Author

@coinmoles coinmoles Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, the function has to be public because it is called from the output of #[task_handler] macro.

However, it would make sense to make this private and have OperationProcessor::peek_completed and OperationProcessor::take_completed_result call this before returning. Do you think that would be better?

Copy link
Collaborator

@alexhancock alexhancock Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, something like that makes sense to me. Can you make the change?

if let Some(receiver) = &mut self.task_result_receiver {
while let Ok(result) = receiver.try_recv() {
self.running_tasks.remove(&result.descriptor.operation_id);
self.completed_results.push(result);
}
}
std::mem::take(&mut self.completed_results)
}

/// Check for tasks that have exceeded their timeout and handle them appropriately.
Expand Down
3 changes: 2 additions & 1 deletion crates/rmcp/tests/test_task.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,8 @@ async fn executes_enqueued_future() {
.expect("submit operation");

tokio::time::sleep(Duration::from_millis(30)).await;
let results = processor.collect_completed_results();
processor.collect_completed_results();
let results = processor.peek_completed();
assert_eq!(results.len(), 1);
let payload = results[0]
.result
Expand Down