A step stopped by the operator is recorded and drawn as failed: say "interrupted", in a calm tone #152

Open
opened 2026-10-06 01:41:01 -04:00 by cmoriarty · 0 comments
Owner

Stop Run works, but afterwards the console tells a story of failure. The step that was running shows a red ✗ and "failed", its band says "1 failed", Step details lists the attempt as "#1 failed", and the transcript ends with a red "✗ interrupted" and "Implement task group 2 — failed".

Cause

An attempt that ends because of the operator's interrupt finishes with reason aborted (AgentExecutor, TerminalReason.ABORTED) and is recorded as osf.step.failed. StepStatus.INTERRUPTED exists, and the console has a look for it, but nothing ever sets it, and that look uses the error tone (text-bad).

Want

When the operator ends a step with Stop, whether on the run or on the step, the step is interrupted, not failed, everywhere it is shown:

  • Engine: the step lands in interrupted. A timeout, budget abort or crash stays failed. Mediation (#119) does not retry an interrupted step. Resume accepts one. The run stays abandoned (shown as "stopped").
  • Spine: the step row reads "interrupted" in a calm tone (■, muted or signal, not red). The band header counts it as "1 interrupted", not under failed.
  • Step details: the attempt reads "#1 interrupted", not red.
  • Transcript: the abort that opencode echoes after a Stop, and the task card for the group that was cut short ("Implement task group 2"), read "interrupted"/"stopped", not "failed", and not in the error tone.
  • Run list (rail): a stopped run keeps its muted ■ "stopped" look, with no red ✗ or red progress bar. Only a run that really failed is drawn in red. (Runs 48, 38 and 37 are red because they really failed, at the judge, at the merge and at code review.)

A simulated run (osf.sim) that stops a run mid-apply should cover the engine side, and a browser spec the console side.

Stop Run works, but afterwards the console tells a story of failure. The step that was running shows a red ✗ and "failed", its band says "1 failed", Step details lists the attempt as "#1 failed", and the transcript ends with a red "✗ interrupted" and "Implement task group 2 — failed". ## Cause An attempt that ends because of the operator's interrupt finishes with reason `aborted` (`AgentExecutor`, `TerminalReason.ABORTED`) and is recorded as `osf.step.failed`. `StepStatus.INTERRUPTED` exists, and the console has a look for it, but nothing ever sets it, and that look uses the error tone (`text-bad`). ## Want When the operator ends a step with Stop, whether on the run or on the step, the step is **interrupted**, not failed, everywhere it is shown: - **Engine:** the step lands in `interrupted`. A timeout, budget abort or crash stays `failed`. Mediation (#119) does not retry an interrupted step. Resume accepts one. The run stays `abandoned` (shown as "stopped"). - **Spine:** the step row reads "interrupted" in a calm tone (■, muted or signal, not red). The band header counts it as "1 interrupted", not under failed. - **Step details:** the attempt reads "#1 interrupted", not red. - **Transcript:** the abort that opencode echoes after a Stop, and the task card for the group that was cut short ("Implement task group 2"), read "interrupted"/"stopped", not "failed", and not in the error tone. - **Run list (rail):** a stopped run keeps its muted ■ "stopped" look, with no red ✗ or red progress bar. Only a run that really failed is drawn in red. (Runs 48, 38 and 37 are red because they really failed, at the judge, at the merge and at code review.) A simulated run (`osf.sim`) that stops a run mid-apply should cover the engine side, and a browser spec the console side.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cmoriarty/braid#152
No description provided.