Task Dependency Scheduler · Analysis

01 · Frame the problem

Understand the central challenge

Design an in-process executor for a finite directed acyclic task graph. Tasks may fail, dependants must not run prematurely and duplicate completion callbacks must not release a dependency twice.

Dependencies define when a task becomes eligible, while concurrency limits define when eligible work starts. Analyse cycles, repeated completion, failure propagation and cancellation before dispatching any user callbacks.

02 · Find the design pressure

Start simple, then identify the gap

Begin with validated graph indegrees and a ready queue. Starting tasks during validation can produce partial execution before discovering a cycle. Apply each terminal transition once and execute callbacks outside the scheduler's shared-state boundary.

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.

03 · Define success

Requirements to preserve

Reject missing dependencies and cycles before running any task.
Run only tasks whose dependencies have all succeeded.
Bound concurrent execution and define failure propagation.
Process each task completion once under concurrency.

04 · Identify the correctness boundary

Invariants, representation and mutation boundaries

Reject cycles before executing any task. Maintain remaining-dependency counts and terminal state transitions under one scheduler boundary, while user work runs outside it. A task becoming terminal twice must not decrement children twice, and failed prerequisites need explicit skip/continue behavior.

05 · Make it concrete

Reason through a worked example

A and B both precede C. A completes twice through duplicate callbacks; C remains blocked until B completes because A's terminal transition is applied once. If B fails under fail-fast policy, C is skipped rather than scheduled with incomplete prerequisites, and started tasks still receive tracked completion handling.