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: Caller responsibility
Add Caller and define its responsibility.
Not yet passed: DAG scheduler responsibility
Add DAG scheduler and define its responsibility.
Not yet passed: Graph validator responsibility
Add Graph validator and define its responsibility.
Not yet passed: Ready queue responsibility
Add Ready queue and define its responsibility.
Not yet passed: Task executor responsibility
Add Task executor and define its responsibility.
Not yet passed: State store responsibility
Add State store and define its responsibility.
Not yet passed: Caller → DAG scheduler
A directed path must connect Caller to DAG scheduler. Arrows represent requests, dependencies, or event flow.
Not yet passed: DAG scheduler → Graph validator
A directed path must connect DAG scheduler to Graph validator. Arrows represent requests, dependencies, or event flow.
Not yet passed: DAG scheduler → Ready queue
A directed path must connect DAG scheduler to Ready queue. Arrows represent requests, dependencies, or event flow.
Not yet passed: DAG scheduler → Task executor
A directed path must connect DAG scheduler to Task executor. Arrows represent requests, dependencies, or event flow.
Not yet passed: DAG scheduler → State store
A directed path must connect DAG scheduler to State store. Arrows represent requests, dependencies, or event flow.
Not yet passed: When should cycle validation happen?
Not yet passed: When is a task ready?
Not yet passed: How should duplicate completion events behave?
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.
Validate the whole DAG, maintain a ready queue and serialize task-state changes while executing work outside the scheduler lock. Conditional terminal transitions preserve dependency counts and concurrency limits. Normalize dependency IDs, reject duplicates/missing tasks and run a topological validation. No task starts until the graph is valid; tasks with no dependencies enter the ready queue. Under a scheduler lock, dequeue eligible tasks up to the configured positive concurrency bound and transition PENDING → RUNNING exactly once. Execute tasks outside the lock. On success, atomically transition RUNNING → SUCCEEDED, release its running slot and decrement each dependent’s remaining-success count once; enqueue newly ready dependants. On failure, mark FAILED and propagate SKIPPED through descendants that require its success, leaving independent branches runnable. Cancellation stops admission and requests cooperative cancellation of running tasks; it does not pretend their effects were rolled back.
There is no single correct diagram. Explain where yours differs and which requirement justifies it.