An interrupt pauses the run and reports itself in full
When a node stops to ask a question, the caller gets a complete answer about what happened: which question is outstanding, which run holds it, and everything that finished before it.
The rule
- When a node raises an interrupt, its job is marked interrupted and carries the interrupt's identifier, and the run is paused.
- The response shape is part of this rule: status
interrupted, the persisted interrupt's public representation (identifier, node identifier, status) under the response metadata, the run's identifier, and results holding every node that completed before the interrupt.
What it means
An interrupt is not reported as a bare "paused" flag. The job that raised it carries the interrupt's own identifier, so a caller reading the job already knows which question it is waiting on. The response goes further: it hands back the persisted interrupt's public shape — its identifier, which node raised it, and its status — under the response metadata, and it hands back every node that finished before the pause. A caller does not have to make a second call to learn what already ran.
The results are exactly the completed prefix, no more: a node reached after the interrupt does not appear at all, not even as an empty placeholder.
Example
A confirmation node interrupts a three-node run partway through.
{
"status": "interrupted",
"results": { "log_before": "…" },
"metadata": {
"interrupt": {
"id": "…",
"nodeId": "confirm",
"status": "pending"
}
}
}The node after the confirmation is missing from results entirely — it never
ran — while the node before it is there in full.