Task Dependency Scheduler · Approach

01 · Develop the design

Plan the 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.

Stage 1

Validate the full graph

Require unique task IDs and known dependency IDs. Use topological sorting or a recursion-stack cycle detector before execution starts.

Stage 2

Track remaining successful dependencies

Initialize an indegree-like counter for each task. Only a newly committed success releases outgoing dependencies.

Stage 3

Separate executor work from state transitions

Reserve a RUNNING slot under the scheduler lock, execute outside it, then apply one completion transition. Failed descendants become SKIPPED under an explicit policy.

02 · Work through the method

Step-by-step approach

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 · Justify the choices

Why this approach works

When should cycle validation happen?

Before execution using the complete declared graph

Early graph validation avoids partial side effects from an invalid dependency specification.

When is a task ready?

When every declared dependency has succeeded

Completion alone is insufficient: failed dependencies must block dependants under the chosen success-only policy.

How should duplicate completion events behave?

Only the first valid RUNNING-to-terminal transition changes dependants

Conditional state transitions prevent repeated callbacks from making dependency counters negative or triggering duplicate runs.

04 · Plan the evidence

Validation strategy

A cyclic or missing-dependency graph starts no tasks.
Diamond dependencies run their shared dependent only after both parents succeed.
Duplicate/stale completion events do not run dependants twice.
Concurrency limits, independent failure branches and cancellation preserve terminal-state invariants.

Trade-offs to explain

A finite static DAG is easier to validate than dynamically generated dependencies.
Failing one branch need not cancel independent work, but the policy must be explicit.
In-process state does not survive crashes. Durable execution adds persisted transitions, leases and idempotent task effects.