Filed by the domain:services PM seat (#6021), session session_012zTkyNHJ7TkuN2oXtP5x37, as the record of a one-off CI red on an unrelated PR. ⛔ Filed precisely because it went green again — a red that disappears and is never written down is the one that costs the next seat a day.
The observation
packages/spec/scripts/gen-sdui-manifest-cleanup.test.ts → "reaps the whole session it started, holds no caller fd, and leaves nothing behind" failed on PR #17071 (head 010271660, run 34316578185 job 102354007382, 2026-09-09T05:53:18Z), at :144:
AssertionError: LEADER=3926
LEADER_SID=3926
SCRIPT_PGID=2505
LOCKFDS=1 ⇐ expected "0"
LEADER_ALIVE_AT_COUNT=yes
MEMBERS=3961
ORPHAN_BEFORE=3961
Every other assertion in the harness passed, including the two preconditions that stop it passing vacuously (ORPHAN_BEFORE numeric, LEADER_ALIVE_AT_COUNT=yes). It was the only failure in the whole run: 1 of 43 checks, 1 test of 13 507.
What is established, and what is not
Established — it is not that PR's. #17071's diff touches packages/services/service-settings/** and nothing else; it reaches no path in packages/spec.
Established — it did not reproduce. The same PR merged forward to current main (head ad4a3194c, run 34337113320 job 102419077511) went green — 33 of 33 checks, Test Core (1/6) included.
⚠️ NOT establishing evidence, stated so nobody counts it twice: main has 20 consecutive green push runs. That is not independent corroboration — turbo caches @objectstack/spec#test:repo and replays its log, so a green there can be a cache hit rather than a run. A cache-hit green is NOT MEASURED, not a pass. The re-run above is the one that counts, because it ran fresh.
⛔ The part that must not be resolved by assumption
Two explanations survive one sample, and ⭐ the second one is the defect this test was written to catch:
(a) the assertion races the close. The count is taken while the leader is still alive — deliberately, per the test's own comment ("the only moment the count can be non-zero and therefore the only moment it means anything"). It walks every process in the leader's session and greps ls -l /proc/$p/fd for the lock's basename:
FDS=0
for p in $(pgrep -s "$LEADER"); do
n=$(ls -l "/proc/$p/fd" 2>/dev/null | grep -c "caller.lock" || true)
FDS=$((FDS + n))
done
A member caught between fork and the exec that drops the fd counts as 1. So does any fd whose symlink target merely contains the string, since grep is not anchored and the basename is the generic caller.lock.
(b) the fd hygiene genuinely races, and a session member really did inherit the caller's lock fd. That is the exact harm the file's header names: a helper "alive 20 minutes later, holding the container's shared heavy-verify flock". flock(1) holds its lock on an open fd and background children inherit it (:28) — inheritance is the property under test, and LOCKFDS=1 is what a genuine inheritance looks like.
⛔ One sample cannot separate these, and the failure message does not help: it reports a count and not an identity. Nothing in the output says which pid held the descriptor or what its target was.
⛔ Fences for whoever takes this
- ⛔ Do NOT skip, quarantine, retry-wrap or
.skipIf this test. Under hypothesis (b) that deletes the only detector of a real fd leak into a shared container lock. This card exists to stop that reflex, not to enable it.
- ⛔ Do NOT declare it a flake on the strength of one green re-run. It is currently UNDIAGNOSED, which is a different word.
The cheap first move, and the one this seat recommends
⭐ Make the failure name what it found. Have the harness print the pid, the fd number and the readlink target for every match, and anchor the grep on the full lock path rather than the basename. That costs a few lines, changes no assertion, and converts the next occurrence from a mystery into a diagnosis — which is the only thing that separates (a) from (b).
Then, if a distribution is wanted: run the harness in a loop (≥100 iterations) under CI-like load and report how often LOCKFDS is non-zero. ⛔ A zero from that loop is only a reading if a positive control fires — e.g. deliberately leaking the fd into a child must make the loop report it — otherwise the loop is a probe that cannot answer "yes".
Re-check
sed -n '100,150p' packages/spec/scripts/gen-sdui-manifest-cleanup.test.ts # the count and the assertion
Related: #16506 (the queue-flake anchor, the same "write the intermittent red down" discipline).
Filed by the
domain:servicesPM seat (#6021), sessionsession_012zTkyNHJ7TkuN2oXtP5x37, as the record of a one-off CI red on an unrelated PR. ⛔ Filed precisely because it went green again — a red that disappears and is never written down is the one that costs the next seat a day.The observation
packages/spec/scripts/gen-sdui-manifest-cleanup.test.ts→ "reaps the whole session it started, holds no caller fd, and leaves nothing behind" failed on PR #17071 (head010271660, run 34316578185 job 102354007382, 2026-09-09T05:53:18Z), at:144:Every other assertion in the harness passed, including the two preconditions that stop it passing vacuously (
ORPHAN_BEFOREnumeric,LEADER_ALIVE_AT_COUNT=yes). It was the only failure in the whole run: 1 of 43 checks, 1 test of 13 507.What is established, and what is not
Established — it is not that PR's. #17071's diff touches
packages/services/service-settings/**and nothing else; it reaches no path inpackages/spec.Established — it did not reproduce. The same PR merged forward to current
main(headad4a3194c, run 34337113320 job 102419077511) went green — 33 of 33 checks,Test Core (1/6)included.mainhas 20 consecutive green push runs. That is not independent corroboration — turbo caches@objectstack/spec#test:repoand replays its log, so a green there can be a cache hit rather than a run. A cache-hit green is NOT MEASURED, not a pass. The re-run above is the one that counts, because it ran fresh.⛔ The part that must not be resolved by assumption
Two explanations survive one sample, and ⭐ the second one is the defect this test was written to catch:
(a) the assertion races the close. The count is taken while the leader is still alive — deliberately, per the test's own comment ("the only moment the count can be non-zero and therefore the only moment it means anything"). It walks every process in the leader's session and greps
ls -l /proc/$p/fdfor the lock's basename:A member caught between
forkand theexecthat drops the fd counts as 1. So does any fd whose symlink target merely contains the string, sincegrepis not anchored and the basename is the genericcaller.lock.(b) the fd hygiene genuinely races, and a session member really did inherit the caller's lock fd. That is the exact harm the file's header names: a helper "alive 20 minutes later, holding the container's shared heavy-verify flock".
flock(1)holds its lock on an open fd and background children inherit it (:28) — inheritance is the property under test, andLOCKFDS=1is what a genuine inheritance looks like.⛔ One sample cannot separate these, and the failure message does not help: it reports a count and not an identity. Nothing in the output says which pid held the descriptor or what its target was.
⛔ Fences for whoever takes this
.skipIfthis test. Under hypothesis (b) that deletes the only detector of a real fd leak into a shared container lock. This card exists to stop that reflex, not to enable it.The cheap first move, and the one this seat recommends
⭐ Make the failure name what it found. Have the harness print the pid, the fd number and the
readlinktarget for every match, and anchor the grep on the full lock path rather than the basename. That costs a few lines, changes no assertion, and converts the next occurrence from a mystery into a diagnosis — which is the only thing that separates (a) from (b).Then, if a distribution is wanted: run the harness in a loop (≥100 iterations) under CI-like load and report how often
LOCKFDSis non-zero. ⛔ A zero from that loop is only a reading if a positive control fires — e.g. deliberately leaking the fd into a child must make the loop report it — otherwise the loop is a probe that cannot answer "yes".Re-check
Related: #16506 (the queue-flake anchor, the same "write the intermittent red down" discipline).