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

[github-actions]

scripts/gen-sdui-manifest-collision.test.ts has ejected 3 distinct pull requests from the merge queue
within a rolling 24 hours. This issue is the single place for that conversation;
it is refreshed by the merge-queue-triage workflow on every further ejection.

PR	queue build
#10396	32406085715
#10433	32408600250
#10466	32430822520

This issue is a NAME, not a diagnosis. The workflow that files it reads the
failing test file path out of the job logs and counts distinct PRs; it does not
know whether this is a flake, a load/timing cliff, a semantic conflict between
queued PRs, or a real regression, and it does not act on any of those. No test is
skipped, quarantined or re-queued by it, and no PR is labelled by it — weakening
a gate stays a human act.

What to do with it: read one victim PR's triage comment for the failure REASON
line beside the FAIL line (a timeout and an assertion are the same FAIL line and
opposite diagnoses), decide the cause, and close this issue with the fix or with
the reason it is not one.

Last refreshed by queue build 32430822520 (PR #10466).

---

Filed by the merge-queue-triage workflow (#4859, aggregation #10128).

[os-zhuang]

⭐ 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

[os-zhuang]

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

[os-zhuang]

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