Jump to a problem, path or page
Jump to a problem, path or page
Updates as you edit. Run the review to record it; passing every check completes the problem.
Not yet passed: TaskGroup responsibility
Add TaskGroup and define its responsibility.
Not yet passed: PendingQueue responsibility
Add PendingQueue and define its responsibility.
Not yet passed: ChildTask responsibility
Add ChildTask and define its responsibility.
Not yet passed: AbortController responsibility
Add AbortController and define its responsibility.
Not yet passed: JoinResult responsibility
Add JoinResult and define its responsibility.
Not yet passed: TaskGroup → PendingQueue
A directed path must connect TaskGroup to PendingQueue. Arrows represent requests, dependencies, or event flow.
Not yet passed: TaskGroup → ChildTask
A directed path must connect TaskGroup to ChildTask. Arrows represent requests, dependencies, or event flow.
Not yet passed: TaskGroup → AbortController
A directed path must connect TaskGroup to AbortController. Arrows represent requests, dependencies, or event flow.
Not yet passed: AbortController → ChildTask
A directed path must connect AbortController to ChildTask. Arrows represent requests, dependencies, or event flow.
Not yet passed: TaskGroup → JoinResult
A directed path must connect TaskGroup to JoinResult. Arrows represent requests, dependencies, or event flow.
Not yet passed: What does aborting a signal guarantee?
Not yet passed: When may join settle?
Not yet passed: How should queued tasks behave after a child fails?
Not yet passed: Interfaces and invariants
Write at least 80 characters describing concrete operations, inputs, outputs, state and errors. This check measures completeness, not semantic correctness.
Not yet passed: Trade-offs and failure cases
Write at least 80 characters about alternatives, failure handling and edge cases. Review the reasoning yourself using the reference discussion.
Rule-based educational feedback. Notes are checked by length only; topology checks confirm directed reachability. These checks do not validate semantics, latency, reliability or every valid design.
Maintain a bounded submission queue and active child set under one event loop. A first failure requests cancellation and skips unstarted children, while join closes submissions and waits for all started children to settle before returning collected outcomes. Validate concurrency and queue bounds. submit accepts a task factory only while OPEN and returns an outcome handle; overload and closed submission are explicit errors. Drain up to the concurrency limit, wrapping synchronous factory throws and immediately observing each returned promise. Store success or failure outcomes and remove the child from the active set in a finalizer. On first failure or explicit cancellation, set the cancellation flag before invoking abort callbacks, skip queued factories and request cooperative cancellation of active tasks. Capture later failures as additional outcomes. join is idempotent and changes OPEN to CLOSING. Continue normal queued work if not cancelled, and settle the shared join promise only when no active or queued work remains. A child ignoring cancellation can keep it pending; diagnostics must not misreport termination.
There is no single correct diagram. Explain where yours differs and which requirement justifies it.