A gate pause leaves no phantom failure in the tool trail
A pause is not a failure, and the record of a tool call must not say otherwise; a mislabelled attempt either holds a finished run open or trips the run's unhandled-failure check.
The rule
- An interrupt escaping a tool invocation records the attempt as interrupted, not failed.
- When the call is resumed it records itself as a new attempt and closes the superseded interrupted one as cancelled, because an attempt left interrupted would hold a finished run paused.
- A failed tool call is recorded as a handled failure by construction (it is delivered to the consumer as a model-recoverable result), so it must not count towards the run's unhandled failures (ERR-9).
- One pause raises exactly one question, however many times the tool plane observes the same interrupt.
What it means
A paused tool call is not a failure sitting in the trail waiting to be relabelled. It is recorded as interrupted from the start, and resuming it does not simply flip that same record to a finished state: the interrupted attempt is closed out as cancelled, superseded by a new attempt of its own that carries the finished status. Two records, not one repurposed — and neither of them is ever a failure, so neither counts toward the run's unhandled failures.
Example
The tool's own record while the run sits paused on the gate:
{ "status": "interrupted", "output": {} }The same node's two job records once the call is resumed:
["cancelled", "completed"]