Workflow: a step whose parent can never reach a terminal status is silently left NOT_STARTED

[thomtrp]

Split out of #24136 (fix for #24060), where both shapes came up but neither is caused by that change.

A step is only evaluated when a parent that reached a terminal status enqueues it, and it can only decide once every parent is terminal. So a parent that can never terminate leaves the child stuck at NOT_STARTED forever. Nothing reports it: the run has no running or pending step left, so it ends COMPLETED with part of the graph untouched.

Two ways to get such a parent.

A cycle inside a branch that was not taken

If/Else A
  ├ (if)   → taken
  └ (else) → X → Y → X

Take the if branch. X's parents are the If/Else (dead, since the branch was not taken) and Y. Y's only parent is X. Neither can move. Both end NOT_STARTED and the run reports COMPLETED.

Nothing rejects a cycle: assertWorkflowConnectionOrThrow only checks the handles are defined, and neither createStepEdge nor the workflow validation utils do an acyclicity check, so the edge can be drawn in the editor.

shouldExecuteIteratorStep already solves exactly this for loops by filtering stepIdsInLoop out of the parents it considers. The same idea generalises: a parent that is a descendant of the step is a back edge and must not block it. In an acyclic graph that filter changes nothing, so it only affects the broken case.

A step made unreachable by graph editing that still points at a live step

deleteStepEdge does no reachability check, and a step that loses its last incoming edge stays on the canvas and keeps its own nextStepIds. It can never run, so any step it points at can never conclude. This one already misbehaves on main.

Here the back-edge filter does not help; it needs the executor to treat a parent that is unreachable from the trigger as dead, or the builder to stop producing the shape.

Both need a user to draw an unusual graph, which is why they were left out of #24136.

[twenty-eng-sync]

Probably a real bug: malformed workflow graphs can leave steps NOT_STARTED while the run is incorrectly marked COMPLETED.
Proposed severity: MEDIUM because workflow execution is incorrect, but it requires unusual cyclic or unreachable graph shapes that users can avoid by repairing the graph.
Root-cause hypothesis (high confidence): packages/twenty-server/src/modules/workflow/workflow-executor/utils/should-execute-step.util.ts waits on all discovered parents, including non-terminating back edges or unreachable parents.
packages/twenty-server/src/modules/workflow/workflow-executor/utils/workflow-should-keep-running.util.ts then stops when no step is running/pending and no completed parent has an executable child, allowing untouched steps to remain.
The report includes concrete graph shapes and expected behavior; an exact release/build version is not provided, although one case is confirmed on main.

[sonarly]

🟠 Sonarly Analysis — High Severity

Deadlocked workflow branches leave runs falsely COMPLETED

Malformed workflow graphs can leave steps in NOT_STARTED forever while the run is marked COMPLETED. Users receive no error even though part of the automation was never executed.

Root Cause

Workflow execution deadlocks when a NOT_STARTED step has an incoming parent that can never reach a terminal status, and the run-level completion check does not recognize that deadlock.

The proximate cause is the combination of:

1. shouldExecuteStep treats every step whose nextStepIds contains the candidate ID as a parent [ref:toolu_should_execute_step_001]. It then delegates to shouldExecuteChildStep, which requires at least one successful parent and requires every parent to be SUCCESS, STOPPED, or SKIPPED [ref:toolu_should_execute_child_step_001]. A cyclic back-edge therefore remains blocked by a descendant that is still NOT_STARTED. An unreachable orphan can create the same condition for any step it still references.

2. When a candidate cannot execute, fail safely, or skip, executeFromStep simply returns without changing its status [ref:toolu_executor_001]. The step consequently remains NOT_STARTED and no later event re-evaluates it unless another terminal parent enqueues it.

3. workflowShouldKeepRunning only keeps a run alive when a PENDING/RUNNING step exists or a completed step has an executable NOT_STARTED child [ref:toolu_workflow_keep_running_001]. A deadlocked component has neither condition. computeWorkflowRunStatus then reaches the unconditional COMPLETED path after execution finishes [ref:toolu_executor_status_001], so the run is falsely completed with untouched graph nodes.

The triggering state is a malformed workflow graph created by editing edges. The issue identifies two concrete forms:

• A cycle in a branch that was not selected, such as X -> Y -> X. The branch is not executed, while the cycle supplies a parent that never becomes terminal.
• Deleting the last incoming edge to a step without removing that step’s outgoing edges. deleteStepEdge only filters the target from the source’s nextStepIds and persists the modified source [ref:toolu_edge_delete_001]; it performs no reachability cleanup. The orphan remains on the canvas and can continue to block descendants.

The graph builder does not prevent the first form: createStepEdge appends an arbitrary target to nextStepIds [ref:toolu_edge_create_001], while the frontend connection assertion validates only that source and target handles exist [ref:toolu_connection_assertion_001]. Activation validation checks the presence and basic validity of the trigger and steps but does not reject cycles or unreachable steps [ref:toolu_activation_validation_001].

The exact production workflow, workspace, timestamp, occurrence count, and whether the reported run used the cyclic-branch or orphaned-step shape are unavailable. No Sentry exception or stack trace exists because this is a silent state-machine failure, not a thrown error.

Blame commit: 2f7d8c76 by martmull — 22 branches 2 (#13051)

Suggested Fix

Added workflowHasDeadlockedSteps to detect NOT_STARTED steps after normal execution and branch-processing checks have stalled. Workflow runs with such steps now end as FAILED with a clear error rather than COMPLETED, preventing silent partial execution from malformed cycles or orphaned graph branches.

---

Analyzed by Sonarly · View full analysis