Workflow Execution

After-commit dispatch and scheduler recovery use the same claim protocol. A capture moves from pending to dispatching under a database-timed lease. Its dispatched status commits in the same transaction as the workflow’s database changes. A crash before that commit leaves a recoverable attempt, rather than a completed marker without its work. The captured user is restored through the execution and commit; an inactive or deleted user yields no user attribution.

Dispatch renews active claims; the scheduler recovers expired claims. The default workflow.capture.lease-seconds is 300 (minimum 3); renewal runs every third of that interval. Claim tokens fence both activity invocation and completion, so an obsolete worker cannot commit its database changes.

Before executing email, agent, or script nodes, dispatch commits a separate effectStarted marker. Scripts are conservative here: they can call services whose effects are outside the workflow transaction. If such an attempt is interrupted, its capture becomes outcome_unknown and is not replayed automatically. Unmarked expired attempts return to pending. A caught dispatch transaction failure is retained as failed, or outcome_unknown when marked. Node failures successfully recorded by the engine still count as dispatched. The effect marker uses a second database connection while the dispatch transaction is open; allow connection-pool headroom for these independent commits.

Inspect unresolved MetaWorkflowCapture records, ensure the original worker has stopped, and check the external systems before deciding whether to replay. The administrator-only Java service method CaptureDispatcher.reconcile(id, replay, reason) requires a nonblank reason: replay=true queues the whole captured event again; false closes it as resolved. The administrator, time, and reason remain on the capture. This method refuses pending, active, and completed captures. There is no capture reconciliation screen yet.

workflow.capture.retain-days defaults to 7 and removes only old dispatched captures. Failed, unknown, and administratively resolved records are retained. Registry eligibility is resolved at dispatch time; the captured registry stamp is diagnostic and does not pin the definitions eligible when the event occurred. This protocol covers record-trigger dispatch; it does not add activity-level checkpoints or retries to other workflow entry points.

A run can end before it runs out of graph: a terminate <end>, a branch that failed, or the record it was about being deleted. Whichever it is, the teardown goes all the way down.

Ending a run cancels every branch of every fork it had open, withdraws the approvals it was holding — both the ones inside a fork and the one a plain task parked on — clears its wake time, and then does the same for every workflow it called and was waiting on, however deep. A caller is closed before its children, so a child finishing mid-teardown cannot resume a caller that is already over.

Deleting the record is the same teardown, reached a different way: the approvals waiting on it are withdrawn from their inboxes, its parked runs become cancelled along with anything they called, and its armed timers are disarmed — there is nothing left to approve or to wake for. The run rows themselves are kept: they are the record’s history, and outlive it.

Cancel run on a waiting run’s form is the same teardown again, for one run, and needs write access to workflow definitions. It asks for confirmation first, because it cannot be undone: the run becomes cancelled, and so does a run waiting on it at a call. A run that an approver or a timer resumed in the meantime is left alone, and the form says so.

Leaving a backlog on an old revision is the default, not the only option. When a change is one the runs already parked should follow — a node renamed, an approval that should now be someone else’s, a graph that was simply wrong — the workflow form offers Migrate, with the number parked on it. It appears only when something is actually parked, and it counts every revision, the current one included: a run can be moved to another node of its own revision, which is how a stuck one is unstuck.

Studio reaches the same dialog from the other end. When Deploy in the workflow designer (Designer) leaves runs parked on the revision it just replaced, it opens the mover on the revision it minted. That is sequencing, not a decision the deploy waits on: the deploy has already committed by the time the dialog appears, so closing it leaves the backlog exactly where the default leaves it, to be moved whenever you like from the workflow form.

The dialog picks one source revision and one target, and shows only that pair. A backlog spread over three revisions is worked through a pair at a time rather than read as one stacked list. The target can be any revision the workflow has ever had, not only the current one: moving a backlog back onto the last known good graph while a broken revision is fixed is a legitimate thing to want, and the rules are the same in both directions.

Each row is a position — a place in the graph where runs are sitting — not a run. A workflow with two thousand parked runs has a handful of positions, because where a run can stop is bounded by the graph rather than by the data, so the dialog stays the same size however large the backlog is. A row’s count opens a picker listing the runs behind it; nothing is selected until you select it, and a row with nothing selected does nothing. Applying an untouched dialog changes nothing at all.

Three things a row can ask for:

Move enters the target node as a fresh arrival. Nothing of the old park is carried across: a timer restarts now from the target node’s own delay, and an approval is opened afresh with the target’s assignee, title and deadline while the old one is taken back. That is the honest reading — you picked the target graph, so the target graph’s deadlines are what you picked — and it is visible to approvers, whose task disappears and comes back.

Cancel gives the run up for good, and End finishes it as a success cut short, which is not the same thing: one is abandoned, the other reaches an ending. Neither replays a node’s effects.

Applying is bounded: a large backlog comes back with what is left, and pressing Apply again continues. A run that an approver or a due timer reached first is reported as already moved on rather than forced. Every move is recorded on the park it closed — where the run went, and who sent it there — so the run viewer can explain a run that changed graphs instead of appearing to teleport between them.