A step that hits its time limit fails with no reason: name the cause, show it in the console, and show the clock

cmoriarty commented

2026-10-01 23:12:37 -04:00

Owner

On production, run run_01M3WX1VW43K77HWNQ328RBGJK (git-flow, cmoriarty/scratch#5, run #36 in the console) failed at agent.test.browser, and the console gave no reason.

The step ran its whole one-hour limit (timeout_s 3600) and the engine stopped it at 3,603 s, before the agent wrote .osf/test/browser.json. The record says only that the file is missing or empty. The attempt row's error_class and error_text are null; the cause, reason: "timed_out", is only on the osf.attempt.closed event, and nothing in the UI reads it. The console shows ✗ interrupted, which reads like a person stopped it, then ✗ agent.test.browser failed. Step details says "#1 failed". The UI never renders error_text, a running step shows no clock against its limit, and the failure email was not sent (no SMTP credentials on the box).

It is the first timeout in production to fail a step (1 of 650 attempts; the other, on 2026-09-28, still passed its file check). The output limit had the same shape in #101 and was fixed for that cause only.

Asked for:

Record the cause. A step that ends on its time limit or its context budget records error_class and error_text on the attempt ("stopped at its 1h limit after 1h 00m"), and the step's failure leads with it, as #101 did for the output limit.
Show it. The console prints error_text under the failed row in the transcript, on the attempt in Step details, and as a one-line reason beside the Failed chip. When the engine stopped the step, the row before the stop says so instead of ✗ interrupted. The notification headline names the step, not its id.
Show the clock. A running agent step shows how long it has run against its limit, turning amber in the last ten minutes.

On production, run run_01M3WX1VW43K77HWNQ328RBGJK (git-flow, cmoriarty/scratch#5, run #36 in the console) failed at agent.test.browser, and the console gave no reason. The step ran its whole one-hour limit (`timeout_s` 3600) and the engine stopped it at 3,603 s, before the agent wrote `.osf/test/browser.json`. The record says only that the file is missing or empty. The attempt row's `error_class` and `error_text` are null; the cause, `reason: "timed_out"`, is only on the `osf.attempt.closed` event, and nothing in the UI reads it. The console shows `✗ interrupted`, which reads like a person stopped it, then `✗ agent.test.browser failed`. Step details says "#1 failed". The UI never renders `error_text`, a running step shows no clock against its limit, and the failure email was not sent (no SMTP credentials on the box). It is the first timeout in production to fail a step (1 of 650 attempts; the other, on 2026-09-28, still passed its file check). The output limit had the same shape in #101 and was fixed for that cause only. Asked for: 1. **Record the cause.** A step that ends on its time limit or its context budget records `error_class` and `error_text` on the attempt ("stopped at its 1h limit after 1h 00m"), and the step's failure leads with it, as #101 did for the output limit. 2. **Show it.** The console prints `error_text` under the failed row in the transcript, on the attempt in Step details, and as a one-line reason beside the Failed chip. When the engine stopped the step, the row before the stop says so instead of `✗ interrupted`. The notification headline names the step, not its id. 3. **Show the clock.** A running agent step shows how long it has run against its limit, turning amber in the last ten minutes.

cmoriarty referenced this issue

2026-10-01 23:13:10 -04:00

A step stopped at its time limit loses a nearly finished report: tell the agent when time is nearly up #117

cmoriarty referenced this issue

2026-10-01 23:13:28 -04:00

The browser subagent cannot use more than one tab, so a five-seat check ran for an hour #118

cmoriarty referenced this issue

2026-10-01 23:39:41 -04:00

A failed step waits for a person: try to fix it and resume it by itself, a bounded number of times #119