Repository navigation
fix(planning): surface-ui-c phase 6 Live check flakes on a loaded test-bash leg #10466
Description
No related issue: new flake found on main's post-merge verify.
Problem
plugins/planning/surface/surface-ui-c.test.sh failed on main at ae46394 in run 40513232280 (test-bash (5)), turning main red. The commit in that range (#10397) touches only pr-merge scripts, and the run at 36529c5 (40509715007) passed with the same planning code, so this reads as a timing flake under a loaded leg.
Failing assertions, from the job log:
FAIL: ui_c.6: FAIL a waiter present: the header reads Live [Claude is working]
FAIL: ui_c.6: FAIL reading with no lease and no waiter: the header reads Claude is working, not Live or Not listening
Likely cause (UNVERIFIED)
plugins/planning/surface/tests/ui_c.js:614-616 starts a 6 s api/wait request and waits only 5 s for the header to read Live. On a crowded runner the waiter may register after the 5 s window. The second failure (lines 621-625, 20 s wait for the working state after the lease release) may follow from the same slow runner; its cause is not traced.
Acceptance criteria
- The phase-6 Live check waits on the server's own listener state (waiters >= 1) before asserting the header, rather than a fixed 5 s window shorter than the waiter it starts.
- The cause of the "reading with no lease and no waiter" failure is traced and fixed, or shown to follow from the first.
Post-merge check (not lane work)
A session re-runs surface-ui-c.test.sh 10 consecutive times on a test-bash leg after the fix merges, and reopens this issue on a failure. The lane cannot run repeated runs.
Activity
github-actions commentedon Oct 27, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: the phase-6 "Live" check in the surface-ui-c test flaked on a loaded test-bash leg and turned main red. The likely cause is a fixed 5 s header wait that is shorter than the 6 s waiter the test starts. The fix is to wait on the server's listener state before asserting. The second failure ("no lease and no waiter") still needs tracing, or needs to be shown to follow from the first. The 10-run re-check is a post-merge step for a session, not lane work. Nothing is missing, and I found no duplicate among the open issues.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 27, 2026
Not admitted to the issue lane: its done-when asks for what an unattended lane run cannot perform: item 3 (a repeated run: "surface-ui-c.test.sh passes 10 consecutive runs on a test-bash leg."); recommended split: keep the other items here as the admissible issue and move these to a needs-human child issue. Admission takes the issue once each of those is met, when intake triages it again (
.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 27, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.kyle-sexton commentedon Oct 27, 2026
Decided on the facts. Admission (#10466 (comment)) held this on item 3, 10 consecutive runs on a test-bash leg, which the lane cannot run. That is admission mechanics, not an owner reason. Instead of splitting it into a child issue, it moved to a post-merge check in the body that a session runs after the fix merges.
Acceptance criteria
kyle-sexton commentedon Oct 27, 2026
Second occurrence, different phases: main run https://github.com/melodic-software/claude-code-plugins/actions/runs/40545685476 (test-bash (5), 17:00Z, head 91367be, a commit that touches only pr-require-checks.yml). ui_c.1:
page.click: Timeout 30000ms exceededwaiting for.rail-list .qbtn[data-q="P2"]; ui_c.2: the changed notice stayed hidden before Save, then#dlgOkclick timed out. So the slow-runner timing affects phases 1 and 2 as well as phase 6; the fix should cover the whole suite's fixed waits, not phase 6 alone.melodic-automation-lanes commentedon Oct 27, 2026
The work-resolve-issue run that
agent-readystarted failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock removed and addedagent-readyback to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.docs(planning): scope the #10466 changelog entry to the test fix
fix(planning): wait on page and server state across the surface-ui-c …
fix(planning): settle before counting the failed visual's re-fetches
kyle-sexton commentedon Oct 28, 2026
Post-merge check:
plugins/planning/surface/surface-ui-c.test.shran 10 consecutive times on main 8dcdac6 (contains #10536): pass=10 fail=0. These ran on a 24-core host, not on a CI test-bash leg: a session cannot repeat that leg cheaply. Before merge the same suite passed 20/20 with one busy loop per core; the pre-fix code also passed under that load, so the local runs cannot reproduce the CI flake. The issue stays closed; reopen it if a CI test-bash leg fails surface-ui-c again.