Queue-flake anchor: scripts/gen-sdui-manifest-collision.test.ts #10447

Activity

1. github-actions

   added

   finding

   on Aug 20, 2026
2. os-zhuang commented on Aug 21, 2026

   

   os-zhuang

   on Aug 21, 2026 – with Claude

   Contributor

   More actions

   ⭐ Diagnosed, and the fix is written and queued — this anchor can close when #10456 merges

   domain:devx PM seat. This issue asks for a cause and a fix, and both exist; linking them here so the diagnosis is not re-derived a fourth time.

   Cause — measured, and it is not what anyone assumed. Tracked as #10370. Everyone reading these evictions (including me, twice, in writing) assumed an external process was holding port 5180, and nobody could name it. Nobody could name it because there wasn't one: the harness's occupier bound the port sdui_pick_free_port had just handed it, and a reservation is not a bind — the port stays takeable in the gap between the pick returning and the occupier binding, and the harness's own port_held helper binds that exact port milliseconds later. Measured over 80 trials on an idle container:

   probe won the bind   39/80    # the two genuinely race
   occupier died         1/80    # its bind landed inside the probe's hold
   

   ⇒ Self-inflicted, not environmental. Not a flake, not a load cliff, not a semantic conflict between queued PRs, not a regression — which is all four of the possibilities this anchor's body correctly says it cannot distinguish between.

   A second, independent cause explains why every capture was unreadable. scripts/gen-sdui-manifest.sh is set -euo pipefail at its top, so sourcing it turns errexit back ON, overriding the set -uo pipefail written one line earlier. Once the occupier had exited, the cleanup kill returned 1, errexit aborted the harness, execFileSync threw in the describe body, and vitest reported 0 test with a bare Command failed — pre-empting every assertion that would have named the problem.

   Fix: PR #10456, green on 31 checks, currently queued and unmerged. The occupier now binds :0 and reports back the port the kernel gave it from inside the listening callback, so it already holds the port when it names it. The harness exits 0 unconditionally and every measurement is a graded KEY=VALUE line, so a future failure of this kind fails as an assertion printing the whole seen map rather than as a bare harness crash.

   ⚠️ The victim list here is a floor, and short by two

   This anchor names three. Measured directly from job logs, the signature has evicted or reddened at least five distinct PRs:

   PR	when	signature
   #10365	~17:00Z	BUSY_HELD=no / BUSY_PORT=5180 / PICKED_WITH_BUSY=5181
   #10396	19:03Z	identical, byte for byte
   #10433	~19:4xZ	(from this anchor; not independently checked by me)
   #10441	19:22Z	identical, byte for byte
   #10466	00:11Z	same harness death

   #10365 and #10441 are missing here because the aggregating workflow's own caveat applies — its 24h comment ledger is read only five pages deep, so its distinct-PR count is a lower bound, not a census. Worth knowing before anyone reads "3" as the cost.

   ⚠️ One thing NOT to read into the #10466 log

   That capture carries ✗ the dev server this run started is no longer running. three times, which looks like a new symptom and is not. That line comes from gen-sdui-manifest.sh:397, and the harness provokes it deliberately at gen-sdui-manifest-collision.test.ts:188 and :202 before asserting expect(seen.OUR_LEADER_ALIVE).toBe('no') at :295 — it is the neighbour-refusal path working correctly, surfacing as interleaved stderr. I posted the opposite reading on #10456 before tracing it and have withdrawn it there.

   ⇒ Suggested disposition: leave this open until #10456 merges, then close it citing that PR. ⛔ I am not closing it myself while the fix is unmerged, and ⛔ not relabelling — finding grading is triage's field.

   ---

   Generated by Claude Code
3. os-zhuang

   added

   domain:devx

   pm:blocked

   and removed

   finding

   on Aug 21, 2026
4. os-zhuang commented on Aug 21, 2026

   

   os-zhuang

   on Aug 21, 2026 – with Claude

   Contributor

   More actions

   Triage (this anchor is a name, not a work item — dropping the auto-applied finding label so it stays out of the ungraded pool): parked pm:blocked on the fix already in flight.

   Blocked-by: #10370

   Rationale: the named test file is exactly the harness #10370 diagnoses — it binds the fixed base port 5180, so any concurrent sdui run reds an unrelated queued PR; three ejections in 24h matches that mechanism. When #10370's fix lands, the unlock scan returns here: if a fourth ejection occurs on a ref containing the fix, the diagnosis is wrong and this anchor needs a fresh read (check the victim PR's triage comment REASON line per the anchor's own instructions). ⛔ No re-queue, no skip, no quarantine from this seat.

   ---

   Generated by Claude Code
5. os-zhuang

   closed this as completedon Aug 21, 2026
6. os-zhuang commented on Aug 21, 2026

   

   os-zhuang

   on Aug 21, 2026 – with Claude

   Contributor

   More actions

   Closed — the fix merged.

   PR #10456 merged. Per this anchor's own instruction ("decide the cause, and close this issue with the fix or with the reason it is not one"), the cause was decided and the fix has landed.

   Cause (#10370): not a flake, not a load cliff, not a semantic conflict between queued PRs, not a regression — the four possibilities this anchor correctly said it could not distinguish. It was self-inflicted: the harness's occupier bound the port sdui_pick_free_port had just handed it, and a reservation is not a bind, so the harness's own port_held helper won that race 39 times in 80 on an idle container. Nobody could name the external process holding 5180 because there was never one.

   A second cause explained why every capture was unreadable: gen-sdui-manifest.sh is set -euo pipefail, so sourcing it turned errexit back on, and a cleanup kill returning 1 aborted the harness before any assertion could name the problem.

   Fix: the occupier now binds :0 and reports back the port the kernel gave it from inside the listening callback, so it already holds the port when it names it. The harness exits 0 unconditionally with every measurement a graded KEY=VALUE line — so a future failure of this class prints the whole seen map instead of a bare Command failed.

   ⚠️ For the record, the victim count here was a floor. This anchor listed 3; measured from job logs the signature reddened at least five distinct PRs — #10365, #10396, #10433, #10441, #10466. The two missing ones fell outside the aggregating workflow's five-page ledger read, which its own caveat flags. Worth knowing if this anchor shape is used to size a problem again.

   ---

   Generated by Claude Code
7. claude

   removed

   pm:blocked

   on Aug 21, 2026