Filed unassigned and ungraded by the #12537 dev (PR #12646), which measured this while correcting the seam census in packages/rest/src/package-door-declared-code.test.ts. ⛔ Reported, not touched — triage scoped #12537 to that one file, and these are two other files.
Measured, on origin/main @ aa5994e17
The production resolveExecutionContext for the /api/v1/packages direct-mount door:
rest-api-plugin.ts:471 — the only supplier repo-wide: resolveExecutionContext: (req) => restServer.resolvePackageRouteExecutionContext(req)rest-server.ts:1481 — that wrapper is notasync. Whole body: an optional-chained req?.params?.environmentId read, then return this.resolveExecCtx(environmentId, req).catch(() => undefined)rest-server.ts:1453 — private async resolveExecCtx(...), so calling it cannot throw synchronouslypackage-routes.ts:81 — the consumer awaits options.resolveExecutionContext(req).catch(() => undefined), swallowing a rejection a second time
⇒ a production resolver delivers a context or undefined. Its rejections are swallowed twice and land on the 401 anonymous-deny floor; they never reach sendThrownError. The only route from this seam to sendThrownError is a synchronous throw, and the production wrapper has no statement that can make one. Full derivation and the reverse-checks are in PR #12646.
The two sites
1. packages/rest/src/package-routes-coded-error-mapping.test.ts:38-43 — the sharp one. It does not merely count the seam; it explicitly defends the seam's realism:
"That is not a contrived lever — the composition wires it to the RestServer's own identity/RBAC resolution, which is exactly the kind of code that raises a coded 401/403."
The first clause is true. The conclusion does not follow: precisely because that resolution is reached through an async method, the coded 401/403s it raises become rejections, and both rest-server.ts:1483 and package-routes.ts:81 swallow them before the door sees anything. The lever is exactly as contrived as this sentence denies — a reader is told the opposite of what the composition does.
2. packages/rest/src/package-door-5xx-message-sanitization.test.ts:341-347 — milder, same family.
"the resolver throw is the one path that reaches the outer catch on this route regardless of what either data source does, so it keeps proving the DOOR rather than one source"
True as a statement about the test. But "keeps proving the DOOR" reads as a claim about a production path, and no production throw reaches that catch through this seam.
Both files drive the seam with a deliberately non-asyncvi.fn(() => { throw error; }) — a sync throw — which is itself the tell: an async one would reject and be swallowed into a 401.
Suggested shape, not a ruling
The same shape PR #12646 used: ⛔ do not delete either case — each still pins real door behaviour, and reached() keeps them from going vacuous. Relabel them as test-only injection points, state the reason once and cite it from the other sites rather than copying it.
Re-check
git grep -n "resolveExecutionContext" origin/main -- packages/rest/src/package-routes-coded-error-mapping.test.ts packages/rest/src/package-door-5xx-message-sanitization.test.ts
git grep -n "resolvePackageRouteExecutionContext" origin/main -- packages/rest/src
⛔ Reverse-check any zero with a term known present in the same file, and never a substring of the term under test.
Fences
⛔ packages/rest/src/rest-server.ts is held by PR #12421 (#11926) — reading it is fine, writing is not. Neither file named above is held by that PR.
Dedup
Searched open issues for this seam / these files; the only related card is #12537, whose graded scope is package-door-declared-code.test.ts alone. No open card covers these two files.
Severity not judged.
Refs
Generated by Claude Code
Filed unassigned and ungraded by the #12537 dev (PR #12646), which measured this while correcting the seam census in
packages/rest/src/package-door-declared-code.test.ts. ⛔ Reported, not touched — triage scoped #12537 to that one file, and these are two other files.Measured, on
origin/main@aa5994e17The production
resolveExecutionContextfor the/api/v1/packagesdirect-mount door:rest-api-plugin.ts:471— the only supplier repo-wide:resolveExecutionContext: (req) => restServer.resolvePackageRouteExecutionContext(req)rest-server.ts:1481— that wrapper is notasync. Whole body: an optional-chainedreq?.params?.environmentIdread, thenreturn this.resolveExecCtx(environmentId, req).catch(() => undefined)rest-server.ts:1453—private async resolveExecCtx(...), so calling it cannot throw synchronouslypackage-routes.ts:81— the consumerawaitsoptions.resolveExecutionContext(req).catch(() => undefined), swallowing a rejection a second time⇒ a production resolver delivers a context or
undefined. Its rejections are swallowed twice and land on the 401 anonymous-deny floor; they never reachsendThrownError. The only route from this seam tosendThrownErroris a synchronous throw, and the production wrapper has no statement that can make one. Full derivation and the reverse-checks are in PR #12646.The two sites
1.
packages/rest/src/package-routes-coded-error-mapping.test.ts:38-43— the sharp one. It does not merely count the seam; it explicitly defends the seam's realism:The first clause is true. The conclusion does not follow: precisely because that resolution is reached through an
asyncmethod, the coded 401/403s it raises become rejections, and bothrest-server.ts:1483andpackage-routes.ts:81swallow them before the door sees anything. The lever is exactly as contrived as this sentence denies — a reader is told the opposite of what the composition does.2.
packages/rest/src/package-door-5xx-message-sanitization.test.ts:341-347— milder, same family.True as a statement about the test. But "keeps proving the DOOR" reads as a claim about a production path, and no production throw reaches that catch through this seam.
Both files drive the seam with a deliberately non-
asyncvi.fn(() => { throw error; })— a sync throw — which is itself the tell: anasyncone would reject and be swallowed into a 401.Suggested shape, not a ruling
The same shape PR #12646 used: ⛔ do not delete either case — each still pins real door behaviour, and
reached()keeps them from going vacuous. Relabel them as test-only injection points, state the reason once and cite it from the other sites rather than copying it.Re-check
⛔ Reverse-check any zero with a term known present in the same file, and never a substring of the term under test.
Fences
⛔
packages/rest/src/rest-server.tsis held by PR #12421 (#11926) — reading it is fine, writing is not. Neither file named above is held by that PR.Dedup
Searched open issues for this seam / these files; the only related card is #12537, whose graded scope is
package-door-declared-code.test.tsalone. No open card covers these two files.Severity not judged.
Refs
resolveExecutionContextseam is TEST-ONLY —resolveExecCtxisprivate asyncbehind.catch(() => undefined), so no production throw leaves it #12537 — the card that scoped the census fix to one fileGenerated by Claude Code