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

Merged

coilysiren merged 1 commit from issue-899-progress-keeps-updating into main

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

coilyco-ops commented

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

Member

Neither the cadence stalled nor the telemetry went quiet. The element hit a cap and stopped talking.

The arithmetic

narrateWait returned without editing once len(p.waits) reached maxProgressWaitLines, which is 12. Wait lines land on the turnProgressEvery grid of 10s, after a line posted at turnProgressAfter of 5s.

5s + 12 x 10s = 125s

The report is 130 to 140 seconds. That is 125 plus one tick of granularity, and the "appears to resume or complete later" is the reply landing and replacing the line.

Why the cap was sized that way

Its own comment: "The turn ceiling over the beat is the natural count." It was sized on the assumption that a turn cannot outlive twelve beats. Turns do. sirens-echo#858 records round 0 alone ranging 133.5s to 255.4s on this lane.

The fix

A full column advances its last line in place instead of stopping. The cap keeps doing the job it exists for, bounding how tall a stuck turn's column grows, and stops bounding how long the element reports. The footer's elapsed count rides the same edit, so both halves stay live.

Raising the number would have moved the wall rather than removed it, which is why this is not a knob change.

Note for the reviewer

TestTheWaitColumnIsBounded asserted len(sink.edits) == maxProgressWaitLines, which pinned the stall as the intended bound. It is renamed to TestTheWaitColumnIsBoundedAndKeepsUpdating and now asserts one edit per beat, the column still capped at 12 lines, and the newest elapsed appearing in the final body.

Touches docs/sirens-echo-progress.md, which was at its character cap, so five restatements elsewhere on the page were compressed. Those edits are confined to paragraphs the #901 branch does not touch, so the two do not conflict.

just gate PASS.

closes #899

Neither the cadence stalled nor the telemetry went quiet. The element hit a cap and stopped talking. ## The arithmetic `narrateWait` returned without editing once `len(p.waits)` reached `maxProgressWaitLines`, which is 12. Wait lines land on the `turnProgressEvery` grid of 10s, after a line posted at `turnProgressAfter` of 5s. ``` 5s + 12 x 10s = 125s ``` The report is 130 to 140 seconds. That is 125 plus one tick of granularity, and the "appears to resume or complete later" is the reply landing and replacing the line. ## Why the cap was sized that way Its own comment: *"The turn ceiling over the beat is the natural count."* It was sized on the assumption that a turn cannot outlive twelve beats. Turns do. sirens-echo#858 records round 0 alone ranging 133.5s to 255.4s on this lane. ## The fix A full column advances its last line in place instead of stopping. The cap keeps doing the job it exists for, bounding how tall a stuck turn's column grows, and stops bounding how long the element reports. The footer's elapsed count rides the same edit, so both halves stay live. Raising the number would have moved the wall rather than removed it, which is why this is not a knob change. ## Note for the reviewer `TestTheWaitColumnIsBounded` asserted `len(sink.edits) == maxProgressWaitLines`, which pinned the stall as the intended bound. It is renamed to `TestTheWaitColumnIsBoundedAndKeepsUpdating` and now asserts one edit per beat, the column still capped at 12 lines, and the newest elapsed appearing in the final body. Touches `docs/sirens-echo-progress.md`, which was at its character cap, so five restatements elsewhere on the page were compressed. Those edits are confined to paragraphs the #901 branch does not touch, so the two do not conflict. `just gate` PASS. closes #899

coilyco-ops added 1 commit

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

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

ci / image-build (pull_request) Successful in 33s

Details

ci / test (pull_request) Successful in 58s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

c55c65da85

The indicator did not stall and the telemetry did not go quiet. narrateWait
returned without editing once len(p.waits) reached maxProgressWaitLines, which
is 12, and the wait lines land on the turnProgressEvery grid of 10 seconds
after a line posted at 5. Twelve beats is 125 seconds, which is the reported
130 to 140.

The cap's own comment said "the turn ceiling over the beat is the natural
count", so it was sized on the assumption that a turn cannot outlive twelve
beats. Turns demonstrably run past that, and sirens-echo#858 records round 0
alone at 170.9s.

A full column now advances its last line in place rather than stopping. The
cap keeps doing what it exists for, bounding how tall a stuck turn grows, and
stops bounding how long the element reports. The footer's elapsed count rides
the same edit, so both halves stay live for the whole turn.

TestTheWaitColumnIsBounded asserted the stall as the bound, so it is renamed
and now asserts one edit per beat with the column still capped and the newest
elapsed reported.

closes #899

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

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

coilyco-ops referenced this pull request

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

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