request: replace try_join_all with JoinSet in plan handlers#549
request: replace try_join_all with JoinSet in plan handlers#549eduralph wants to merge 3 commits into
Conversation
Replace futures::future::try_join_all with tokio::task::JoinSet in single_plan_handler and multi_store_handler to join tasks as they complete rather than collecting all handles first. This provides better error handling with explicit JoinError propagation. Signed-off-by: Ping Yu <yuping@pingcap.com>
Signed-off-by: Ping Yu <yuping@pingcap.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughChangesConcurrent request aggregation
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant RequestPlan
participant JoinSet
participant WorkerTasks
RequestPlan->>JoinSet: spawn indexed shard or store tasks
JoinSet->>WorkerTasks: await task completion
WorkerTasks-->>JoinSet: return indexed results
JoinSet-->>RequestPlan: return ordered results or JoinError
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…rror contract Follow-ups to the JoinSet conversion: - tokio's requirement was "1", but JoinSet stabilized in tokio 1.21 — a downstream holding tokio 1.0-1.20 in its lockfile would satisfy the manifest yet fail to compile this crate. Raise the floor so every permitted resolution exposes the API. - sort the JoinSet import where rustfmt wants it. - state collect_join_set_results' contract in a doc comment: an error return means no further effects from this call; remaining tasks are aborted, never detached. Documents the behavior change that fixes tikv#534. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Eduard R. <eduard@ralphovi.net>
95f74d2 to
4b45517
Compare
|
For the record, the earlier |
Closes #534. Supersedes #535 — offered so the fix isn't blocked on rebase logistics. It carries @pingyu's two commits unchanged, authorship and sign-off preserved, plus one follow-up commit.
Why superseding: #535's merge conflict consists entirely of its dependency-pin commit for rust-toolchain 1.84.1, obsolete since #530 moved the toolchain to 1.93. With that commit dropped, the change rebases onto master with no conflicts. @pingyu — if you'd rather rebase #535 itself, say the word and I'll close this one.
The follow-up commit: raises tokio's floor to 1.21 (
JoinSetstabilized there;tokio = "1"permitted resolutions that can't compile this crate), appliescargo fmt, and adds the doc comment the #535 review asked for — stating the contract that an error return means no further effects: remaining tasks are aborted, never detached (the old detach-on-error could complete stray writes after an observed failure, beyond the #534 panic).Verification:
cargo test --lib67/67 (including the spawn-order test); clippy + fmt clean at 1.93; and a differential parity harness (getwyrd/client-rust-test) driving client-go and client-rust through identical multi-region scenarios shows no wire-visible behavior change.Summary by CodeRabbit
Bug Fixes
Chores