FlowDrop Workflow Specification 1.0-draft

A terminal run refuses re-entry; re-running makes a new run

This is what makes cancellation durable: no requeue or rerun can resurrect a dead run and fire its side-effecting nodes again.

The rule

Normative: this is the rule
  1. A run in a terminal status (completed, failed or cancelled) refuses re-entry, on every path that could re-enter it: no work is executed and the run is left untouched.
  2. Re-running always creates a new run, seeded with the source run's input and recording which run it is a re-run of.

What it means

Re-running is not resuming. A run that already reached completed, failed or cancelled is dead, and re-entering it — through whichever door tries — does nothing: no work executes and the run's own record is left exactly as it was. What looks like "starting it again" always means a second, independent run, seeded with the first one's input.

That second run starts from scratch, not from wherever the first one left off. It carries the same input the dead run carried, but its own status begins at the beginning — nothing about a terminal run's outcome, progress or identity survives into the run created from it, beyond the input and a record of which run it was re-run from.

Example

A cancelled run carrying one input value, and the run created by re-running it.

A cancelled run's stored inputcancelled
{ "answer": 42 }
The new run created by re-running itpending
{ "input": { "answer": 42 } }

The new run also records which run it was re-run from; the cancelled run keeps its status untouched.

Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · INT-11 · changed in spec 1.0