Skip to content

fix(runner): use select_all for true concurrent fail-fast - #68

Closed
0xReLogic wants to merge 1 commit into
mainfrom
fix/parallel-select-all
Closed

0xReLogic wants to merge 1 commit into
mainfrom
fix/parallel-select-all

Conversation

@0xReLogic

@0xReLogic 0xReLogic commented Sep 23, 2026 •

Copy link
Copy Markdown
Owner

Summary

Fixes the follow-up concern raised in #58 the collect_parallel_results function was awaiting task handles sequentially, meaning a slow task at index 0 would block detection of a fast failure at index N.

Changes

  • Replace sequential for handle in handles loop with futures_util::future::select_all for true concurrent monitoring
  • As soon as any task fails, all remaining siblings are aborted immediately regardless of their position in the list
  • Add test: slow task first, fast failing task last validates the concurrent fail-fast scenario
  • Add test: empty handle input edge case

Tests

All unit tests pass:

test collect_parallel_results_succeeds_when_all_tasks_ok ... ok
test collect_parallel_results_handles_empty_input ... ok
test collect_parallel_results_aborts_remaining_tasks_on_failure ... ok
test collect_parallel_results_aborts_slow_first_task_when_later_task_fails ... ok

Closes the improvement suggested in #58.

… steps

Replace sequential await loop in collect_parallel_results with
futures_util::future::select_all so that a failing task aborts all
siblings immediately, regardless of task order in the handle list.

The previous implementation awaited handles one-by-one, meaning a slow
task at index 0 would block detection of a fast failure at index N.

Also adds:
- Test for slow-first / fast-fail-last concurrent scenario
- Test for empty handle input edge case
@0xReLogic 0xReLogic closed this Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant