Canceled blockers are treated as satisfied dependencies and can start dependent work without prerequisite output

[moses4wen]

Summary

Current blocked-by handling treats a blocker in Linear's canceled state as resolved, so a parked dependent session can wake and start even when the canceled blocker never produced the prerequisite work.

This appears to be intentional in the original dependency-deferral design (#1004), which says parked sessions wake when blockers complete or are canceled. The concern is that canceled is ambiguous in coding workflows:

1. Dependency no longer required → continuing may be correct.
2. Required work was abandoned / failed / superseded without replacement → continuing is unsafe because the downstream task may start without required code or artifacts.

Current behavior

On current main, checkBlockedByDependencies() treats both completed and canceled as resolved states:

if (
  state &&
  state.type !== "completed" &&
  state.type !== "canceled"
) {
  unresolvedBlockers.push(...)
}

The state-change wake path likewise reacts to both completed and canceled transitions.

Reproduction

Using three Linear issues:

• A
• B
• C, with C blocked by A

Observed live behavior:

1. Cyrus parks C while A is unresolved.
2. A is moved to Canceled rather than Done.
3. Cyrus logs that blockers are resolved and starts C a few seconds later.
4. A never produced the prerequisite implementation that C was expected to depend on.

Why this matters

For autonomous coding workflows, a canceled prerequisite is not equivalent to a successfully satisfied dependency. Starting downstream work silently can produce incorrect execution against an invalid plan or missing code state.

Suggested direction

I am not proposing that canceled must always remain blocked. A safer semantic could be:

• completed → dependency satisfied → wake automatically
• canceled → dependency outcome is ambiguous → require explicit re-evaluation / policy before waking

If the intended Cyrus semantics are that cancellation always means the dependency relation is no longer required, it would be useful to make that contract explicit. Otherwise I would be happy to contribute a minimal fix and regression tests once the preferred behavior is confirmed.

Related

• Original dependency-deferral implementation: feat: add base branch change notification and blocked-by dependency deferral (CYPACK-978) #1004
• Current code path: packages/edge-worker/src/EdgeWorker.ts (checkBlockedByDependencies and issue-state wake handling)

[Connoropolous]

Good point.

"canceled → dependency outcome is ambiguous → require explicit re-evaluation / policy before waking"
You mean human-in-the-loop here?

[moses4wen]

Not necessarily human-in-the-loop.

What I mean is: canceled alone should not automatically imply "dependency satisfied."

If the blocked-by edge still exists, the safe default is to keep the dependent work blocked. It should proceed only when an authoritative action changes that fact — for example, the dependency edge is removed because the prerequisite is no longer needed, the canceled blocker is replaced by another prerequisite, or an explicit policy says cancellation satisfies that kind of dependency.

That re-evaluation can be automated by the orchestrator/planner. Human input is only needed when the system cannot determine the intended dependency outcome safely.

So the key distinction I’m proposing is:

• completed = prerequisite satisfied
• canceled = prerequisite was not completed, so don’t infer satisfaction from that state alone