Filed unassigned from work on #10370 (PR #10456). ⛔ Not observed failing — recorded as a latent instance of a class that has now cost three PRs a red check in the sibling file, not as a live incident.
Duplicate search first (publish-smoke, STEAL_HELD, harness precondition wording): no open card carries this. #10212 is closed and is about smoke_pick_free_port itself, not the harness that tests it. #10261 (the two registries) is pm:on-hold and a different subject.
The class
#10370's measured mechanism was: a reservation is not a bind.sdui_pick_free_port claims a port through an O_EXCL registry and probes it, then returns — the caller binds afterwards. Anything outside the registry can take the port in that gap, and losing there evaporates the precondition the vacuity guard rests on, which then reads as an accusation of the picker.
packages/spec/scripts/publish-smoke-port-collision.test.ts:305-321 has the same shape, and deliberately widens the gap:
STEAL="$(smoke_pick_free_port 3210)"
rm -f "$SMOKE_PORT_RESERVATION_DIR/$STEAL"# claim released ON PURPOSE
STUB_PORT="$STEAL" STUB_NAME=THIEF node -e "$STUB">/dev/null 2>&1& THIEF=$!
sleep 1
echo"STEAL_HELD=$(curl -sS "http://localhost:$STEAL/"| jq -r .iam)"
The rm -f is correct for what the case tests (a holder the registry knows nothing about), but it means the port is unclaimed for the whole interval between the rm and the stub's listen — anything scanning from 3210 in that window can legitimately take it. Then STEAL_HELD is not THIEF and expect(r.STEAL_HELD).toBe('THIEF') reds a PR that has nothing to do with this area.
Why the exposure is lower than #10370's, and why that is not a reason to leave it
Two things make it rarer than the sdui case, and both are accidents rather than design:
Neither is a property anyone maintains on purpose, and the fix is the one already landed next door.
Shape of a fix — a lead, not a decision
The shape #10370 settled on transfers directly and is small: let the stub bind :0 and report back the port the kernel gave it, so the port it holds is one it provably owns, and drop the pick-then-rm dance entirely. That also makes the "outside the registry" property more obvious rather than less — a port bound straight from the ephemeral range was never claimed in any registry, so there is no claim to remove. See PR #10456 for the landed version, including the ablation that positively controls the guard.
⚠️ Whoever takes this: publish-smoke probes the wildcard address, matching serve.ts's own isPortAvailable, while sdui probes 127.0.0.1. That asymmetry is load-bearing and is recorded on #10261. ⛔ Do not converge them as part of this.
Not in this finding
The harness's second #10370 defect does not apply here: this file already does set +e +o pipefail immediately after sourcing publish-smoke.sh (:135), with a comment naming exactly the failure mode — the sdui sibling was the one that had not caught up, not this one.
Filed unassigned from work on #10370 (PR #10456). ⛔ Not observed failing — recorded as a latent instance of a class that has now cost three PRs a red check in the sibling file, not as a live incident.
Duplicate search first (
publish-smoke,STEAL_HELD, harness precondition wording): no open card carries this. #10212 is closed and is aboutsmoke_pick_free_portitself, not the harness that tests it. #10261 (the two registries) ispm:on-holdand a different subject.The class
#10370's measured mechanism was: a reservation is not a bind.
sdui_pick_free_portclaims a port through anO_EXCLregistry and probes it, then returns — the caller binds afterwards. Anything outside the registry can take the port in that gap, and losing there evaporates the precondition the vacuity guard rests on, which then reads as an accusation of the picker.packages/spec/scripts/publish-smoke-port-collision.test.ts:305-321has the same shape, and deliberately widens the gap:The
rm -fis correct for what the case tests (a holder the registry knows nothing about), but it means the port is unclaimed for the whole interval between thermand the stub'slisten— anything scanning from 3210 in that window can legitimately take it. ThenSTEAL_HELDis notTHIEFandexpect(r.STEAL_HELD).toBe('THIEF')reds a PR that has nothing to do with this area.Why the exposure is lower than #10370's, and why that is not a reason to leave it
Two things make it rarer than the sdui case, and both are accidents rather than design:
port_held, a bind-and-close probe on the very port the occupier was taking, measured winning that bind 39 times in 80. This file's liveness check iscurl+jq, which never binds — so the only racer is a genuine concurrentsmoke_pick_free_portcaller.publish-smoke.shis driven by fewer suites thangen-sdui-manifest.sh.Neither is a property anyone maintains on purpose, and the fix is the one already landed next door.
Shape of a fix — a lead, not a decision
The shape #10370 settled on transfers directly and is small: let the stub bind
:0and report back the port the kernel gave it, so the port it holds is one it provably owns, and drop the pick-then-rmdance entirely. That also makes the "outside the registry" property more obvious rather than less — a port bound straight from the ephemeral range was never claimed in any registry, so there is no claim to remove. See PR #10456 for the landed version, including the ablation that positively controls the guard.publish-smokeprobes the wildcard address, matchingserve.ts's ownisPortAvailable, whilesduiprobes127.0.0.1. That asymmetry is load-bearing and is recorded on #10261. ⛔ Do not converge them as part of this.Not in this finding
The harness's second #10370 defect does not apply here: this file already does
set +e +o pipefailimmediately after sourcingpublish-smoke.sh(:135), with a comment naming exactly the failure mode — the sdui sibling was the one that had not caught up, not this one.