Filed unassigned by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs) after it reddened an unrelated PR. Not graded here — no priority, no domain:*; routing and severity are triage's. Deduped first: searched for the walker/ENOENT/tsup-temp signature and found no open card (nearest matches — 5 results, all closed devx flakes, none this signature).
The failure
Test Core (3/6), job 99349068256, on PR #13514 (card #11974). 1 failed / 1124 passed, and the one failure is in a package the PR does not touch:
FAIL src/security/authz-store-unavailable.test.ts
> [#13279] every transport that authorizes through resolveAuthzContext
> CONTROL: the scanner finds transports at all, and finds THIS repo
Error: ENOENT: no such file or directory, stat
'.../packages/services/service-datasource/tsup.config.bundled_45dgza009nw.mjs'
❯ walk src/security/authz-store-unavailable.test.ts:198:9
❯ discoverTransports src/security/authz-store-unavailable.test.ts:206:10
The failing line is the walker's own statSync:
196| if (entry === 'node_modules' || entry === 'dist' || entry === '.tu…
197| const full = join(dir, entry);
198| if (statSync(full).isDirectory()) walk(full, out);
^
199| else if (full.endsWith('.ts')) out.push(full);
Root cause — a TOCTOU race, not an unexplained flake
readdirSync lists a directory, then statSync is called on each entry. Between those two calls the entry can vanish. Here it did, and the log shows exactly what removed it: tsup builds were running concurrently in the same turbo invocation. Interleaved in the same log, seconds apart:
00:48:43 @objectstack/plugin-security:build: DTS ⚡️ Build success in 20855ms
00:48:44 @objectstack/service-automation:build: cache miss, executing …
00:48:44 @objectstack/core:test: FAIL … ENOENT … service-datasource/tsup.config.bundled_45dgza009nw.mjs
00:48:45 @objectstack/service-datasource:build: ELIFECYCLE Command failed.
tsup.config.bundled_<random>.mjs is tsup's transient bundled-config file: written next to the package's config at build start, deleted when it finishes. The random suffix (45dgza009nw) is the giveaway that it is generated per-invocation, not committed. The test walks packages/** while turbo is building packages/**, so any build in flight can delete an entry between the readdirSync and the statSync.
⇒ The scanner is correct about what it wants and unsafe about how it looks. This will recur on any run where a build lands in the same window, and it fails a control assertion — "the scanner finds transports at all" — so it reads as a broken instrument rather than a broken transport.
Suggested shape, not a prescription
Make the walk resilient to concurrent deletion rather than trying to quiet the builds:
- wrap the
statSync in a try/catch and skip on ENOENT (a file that vanished mid-walk cannot be a transport); or
- use
readdirSync(dir, { withFileTypes: true }) and read Dirent.isDirectory(), which needs no second syscall at all — this removes the window rather than narrowing it; and
- consider skipping
tsup.config.bundled_*.mjs and friends explicitly, alongside the existing node_modules / dist / .tu… exclusions.
⚠️ ⛔ Do not "fix" this by relaxing the control assertion. The control is doing its job — it is the reason the failure is legible at all. The defect is in the walk.
What this does NOT claim
- ⛔ No claim about frequency. Observed once, at 00:48:44Z on 2026-08-31. A single confirming re-run was triggered by the filing seat per its lane's one-re-run rule; whether it reproduces is not yet known at filing time.
- ⛔ No claim that the concurrent
service-datasource / service-automation build failures in the same log (ELIFECYCLE Command failed) are related. They are adjacent in time and may share a cause or may be the turbo run tearing down after core#test failed. Not measured.
- ⛔ No claim about which lane owns this. The fix lands in
packages/core/src/security/authz-store-unavailable.test.ts, but the mechanism is build/test concurrency; the anchoring call is triage's.
Refs: PR #13514 (where it fired) · #11974 (that PR's card) · #13279 (the card the failing test pins)
Filed unassigned by the
domain:servicesPM seat (sessionsession_016ZC5rNQj3WEet5HAmmAkMs) after it reddened an unrelated PR. Not graded here — no priority, nodomain:*; routing and severity are triage's. Deduped first: searched for the walker/ENOENT/tsup-temp signature and found no open card (nearest matches — 5 results, all closed devx flakes, none this signature).The failure
Test Core (3/6), job99349068256, on PR #13514 (card #11974). 1 failed / 1124 passed, and the one failure is in a package the PR does not touch:The failing line is the walker's own
statSync:Root cause — a TOCTOU race, not an unexplained flake
readdirSynclists a directory, thenstatSyncis called on each entry. Between those two calls the entry can vanish. Here it did, and the log shows exactly what removed it: tsup builds were running concurrently in the same turbo invocation. Interleaved in the same log, seconds apart:tsup.config.bundled_<random>.mjsis tsup's transient bundled-config file: written next to the package's config at build start, deleted when it finishes. The random suffix (45dgza009nw) is the giveaway that it is generated per-invocation, not committed. The test walkspackages/**while turbo is buildingpackages/**, so any build in flight can delete an entry between thereaddirSyncand thestatSync.⇒ The scanner is correct about what it wants and unsafe about how it looks. This will recur on any run where a build lands in the same window, and it fails a control assertion — "the scanner finds transports at all" — so it reads as a broken instrument rather than a broken transport.
Suggested shape, not a prescription
Make the walk resilient to concurrent deletion rather than trying to quiet the builds:
statSyncin a try/catch and skip onENOENT(a file that vanished mid-walk cannot be a transport); orreaddirSync(dir, { withFileTypes: true })and readDirent.isDirectory(), which needs no second syscall at all — this removes the window rather than narrowing it; andtsup.config.bundled_*.mjsand friends explicitly, alongside the existingnode_modules/dist/.tu…exclusions.What this does NOT claim
service-datasource/service-automationbuild failures in the same log (ELIFECYCLE Command failed) are related. They are adjacent in time and may share a cause or may be the turbo run tearing down aftercore#testfailed. Not measured.packages/core/src/security/authz-store-unavailable.test.ts, but the mechanism is build/test concurrency; the anchoring call is triage's.Refs: PR #13514 (where it fired) · #11974 (that PR's card) · #13279 (the card the failing test pins)