Turn progress indicator stops updating around 130-140s #899

New issue

Closed

opened 2026-08-17 14:37:54 +00:00 by coilyco-ops-gaming · 1 comment

coilyco-ops-gaming commented

2026-08-17 14:37:54 +00:00

Member

What happens

During long turns, the progress indicator stops updating around 130-140 seconds in, then appears to resume or complete later. Observed during a batch tool test across the MCP roster.

Ask

Determine whether the indicator's update cadence stalls or the underlying turn telemetry goes quiet, then fix it so the indicator keeps updating for the whole turn or reaches a clear terminal state.

## What happens During long turns, the progress indicator stops updating around 130-140 seconds in, then appears to resume or complete later. Observed during a batch tool test across the MCP roster. ## Ask Determine whether the indicator's update cadence stalls or the underlying turn telemetry goes quiet, then fix it so the indicator keeps updating for the whole turn or reaches a clear terminal state.

coilyco-ops-gaming added the

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

label

2026-08-17 14:37:54 +00:00

coilyco-ops added the

labels

2026-08-17 16:34:00 +00:00

coilysiren removed the

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

label

2026-08-17 17:27:34 +00:00

coilyco-ops referenced this issue from a commit

2026-08-17 18:56:22 +00:00

fix: keep the progress line updating past the wait-column cap

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-17 18:56:39 +00:00

fix: keep the progress line updating past the wait-column cap #922

coilyco-ops commented

2026-08-17 18:56:56 +00:00

Member

Built and in review at #922. Angie (ENG, claude seat).

Neither, and the number is exact. The cadence does not stall and the telemetry does not go quiet. narrateWait returns without editing once len(p.waits) reaches maxProgressWaitLines, which is 12. Wait lines land on the 10 second grid after a line posted at 5 seconds:

5s + 12 x 10s = 125s

Your 130 to 140 is that plus one tick of granularity, and "appears to resume or complete later" is the reply landing and replacing the line.

The cap was sized on an assumption that stopped holding. Its own comment reads "The turn ceiling over the beat is the natural count", so twelve beats was meant to be a whole turn. #858 records round 0 alone ranging 133.5s to 255.4s on this lane, so a turn routinely outlives its own narration.

The fix is not a bigger number, which would move the wall rather than remove it. A full column advances its last line in place. The cap keeps bounding how tall a stuck turn grows and stops bounding how long the element reports, and the footer's elapsed count rides the same edit so both halves stay live.

One thing worth knowing for review: TestTheWaitColumnIsBounded asserted len(sink.edits) == maxProgressWaitLines, which pinned the stall as if it were the intended bound. That is how this survived having a test.

Built and in review at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/922. Angie (ENG, `claude` seat). **Neither, and the number is exact.** The cadence does not stall and the telemetry does not go quiet. `narrateWait` returns without editing once `len(p.waits)` reaches `maxProgressWaitLines`, which is 12. Wait lines land on the 10 second grid after a line posted at 5 seconds: ``` 5s + 12 x 10s = 125s ``` Your 130 to 140 is that plus one tick of granularity, and "appears to resume or complete later" is the reply landing and replacing the line. **The cap was sized on an assumption that stopped holding.** Its own comment reads *"The turn ceiling over the beat is the natural count"*, so twelve beats was meant to be a whole turn. #858 records round 0 alone ranging 133.5s to 255.4s on this lane, so a turn routinely outlives its own narration. **The fix is not a bigger number**, which would move the wall rather than remove it. A full column advances its last line in place. The cap keeps bounding how tall a stuck turn grows and stops bounding how long the element reports, and the footer's elapsed count rides the same edit so both halves stay live. One thing worth knowing for review: `TestTheWaitColumnIsBounded` asserted `len(sink.edits) == maxProgressWaitLines`, which pinned the stall as if it were the intended bound. That is how this survived having a test.

coilysiren closed this issue

2026-08-17 19:09:55 +00:00

coilyco-ops referenced this issue from a commit

2026-08-19 02:11:29 +00:00

fix(progress): back the wait narration off instead of editing every beat

coilyco-ops referenced this issue

2026-08-19 02:11:57 +00:00

fix(progress): back the wait narration off instead of editing every beat #1021