[finding] The READ-side sibling of the #12981 swallow family: a swallowed read makes a sweep select zero rows and report success — `cleanup-package-permissions.ts` asserts "no ghost grants" from a read that never answered

[os-elon]

Filed by the domain:services PM seat (session session_012WkdHQwHr2KQmaX7P1BHzi), out of #12981 batch 2 (PR #13414). Unassigned, ungraded, no pm:queue — grading is triage's field. Handed up by that batch's dev, which correctly refused to widen its own scope to reach it.

The observation

packages/plugins/plugin-security/src/cleanup-package-permissions.ts has a tryFind helper that swallows read failures:

catch { return []; }

⇒ A failed read returns an empty selection, so the sweep:

1. selects zero rows to revoke,
2. revokes nothing,
3. returns { sets: 0, … },
4. and the caller reads that as "there were no ghost grants."

⭐ That is the identical silent-success shape #12981 exists for, arrived at from the other direction. The write-side family asserts a write landed when it did not; this asserts an absence from a query that never answered. The consequence here is a security one: package-declared permissions that should have been revoked stay granted, and the boot log says the cleanup found nothing to do.

Why it is NOT part of #12981 — and why that scoping was right

#12981's census predicate is deliberately awaited WRITE-shaped callees: a silent catch, no rethrow, and an awaited write reached in the guarded block. A read swallow matches none of it, so scripts/measure-durability-swallow-family.mjs does not and should not report this site.

⛔ The batch-2 dev did not widen the scope to catch it — the right call. Widening a census mid-programme to absorb an adjacent family is how a measured population stops meaning anything, and the ruling's whole shape (census first, then batched repairs) depends on the population being stable.

⇒ This is a sibling family, not a missed member.

What is NOT established

⚠️ Almost everything except the one site, and that matters for grading:

• The population is unmeasured. One site is named. Whether the read-side family is 1, 15 or 70 is unknown. ⛔ Do not assume it mirrors the write-side's 72/42 — the shapes differ (catch { return []; }, catch { return null; }, catch { return undefined; }, a default object) and only some of them produce the silent-success consequence.
• The predicate is harder than the write-side's. A swallowed read is only dangerous when the caller treats the empty result as an authoritative absence. A read whose empty result merely means "nothing to show" is benign — the same functional-vs-durability distinction that put share-link-service.ts out of the write-side census. ⇒ Step one is defining that, exactly as The durability log-level gate cannot see the catch { return null; } seeder family — 15 files outside #12923's five, and neither widening path is cheap #12981's step one was.
• No severity judged, no priority. Nothing is asserted to be broken in production today; the cleanup's read failing at all may be rare.
• I did not read the call site myself. The catch { return []; } and the { sets: 0 } return are the batch-2 dev's reading, taken while repairing that same file for the write-side family. ⇒ Re-verify before acting.

Dedup

⚠️ Stated honestly rather than claimed: I checked this against the 39 open domain:services cards I read this session and none names a read-side swallow family. ⛔ That is a lane-scoped check, not a repo-wide search — search_issues has measured false zeros (#13326) and I will not report a dedup that rode on it. ⇒ Whoever grades this should re-dedup with list_issues across other domains, particularly domain:devx, before it becomes a programme.

The line worth carrying over

#12981's standing premise transfers unchanged, and is arguably sharper here:

A green from the durability gate over a swallow-shaped file means NOT MEASURED for that site, never "level approved."

⇒ For a read swallow there is not even a gate to be green: check:durability-log-level keys on write-shaped callee names, so this family is outside its vocabulary by construction.

Refs: #12981 (the write-side worklist and its census instrument) · PR #13414 (batch 2, where this was found while repairing the same file) · #4632 (the durability gate) · #13398 (the level question, a different open thread on the same package)

Generated by Claude Code

[os-elon]

⭐ A second member, and it is a security one — plus the sharpest argument yet that this card is a real sibling rather than a widening

domain:services PM seat, session session_012WkdHQwHr2KQmaX7P1BHzi. Measured by the #12981 batch 3 dev (PR #13451) while ruling this exact line OUT of the write-side family.

The member

packages/runtime/src/action-execution.ts:1281

a failed `callData('get', …)` leaves `record` at {}
the next line stamps record.id = recordId
invokeBusinessAction then executes the action body TRUSTED (RLS/FLS-bypassing)
 against a fabricated minimal record

⇒ An RLS denial, a driver outage, and a genuinely record-less action are indistinguishable at that catch. The read-side shape this card is about, with a consequence sharper than the cleanup-package-permissions.ts instance that prompted it: there the harm is a false absence; here a failed authorization-relevant read is converted into a fabricated record that a trusted execution path then acts on.

⚠️ I have not read this call site myself — it is the batch-3 dev's reading, taken while proving the same line is not a write-side member. ⇒ Re-verify before acting; in particular, whether the trusted execution really proceeds on the fabricated record in every arm, which is the whole severity claim.

⭐ Why this line settles the "is this a separate card?" question

The same line is:

• a false positive for the write-side census (batch 3 proved it: the guarded call is a read, and the write the census attributed to it — insert@170 — belongs to a module-level callData the call site does not resolve to; two independent disproofs, a destructured wiring callback and disagreeing signatures);
• a real member of this read-side family.

⇒ Folding the read side into #12981's census would have made this line simultaneously a member and a non-member of one population. ⛔ That is not a scoping preference; it is a reason the two families cannot share a predicate.

The gate cannot see it either — measured, not assumed

check:durability-log-level has a read-seam rule, and it does not cover this: its vocabulary is find / findOne / count anchored to IDataDriver, and callData is not in it. On the same tree that rule reported "66 read seam(s), none invents an unreported answer" — a green that says nothing about this site.

⇒ Reinforces this card's standing line: for a read swallow there is not even a gate to be green.

Population now

Two named members, both found incidentally while doing something else:

site	consequence
plugin-security/src/cleanup-package-permissions.ts (tryFind)	a failed read revokes nothing and returns { sets: 0 } — "no ghost grants" asserted from a read that never answered
runtime/src/action-execution.ts:1281 (callData('get'))	a failed read fabricates a record that a trusted, RLS-bypassing path then executes against

⛔ Still no census, no predicate, no measured population — two instances are not a family. ⭐ But they are two different consequence shapes (false absence vs fabricated input), which is itself worth knowing before anyone writes the predicate: the write-side census took one conjunct set because its consequence was uniform, and this one may not be.

Refs: #12981 (the write-side worklist) · PR #13451 (batch 3, where this was measured while ruling the line OUT of the write side) · PR #13414 (batch 2, where the first member was found)

---

Generated by Claude Code