Skip to content

[finding] check:durability-log-level's read-seam WRAPPER hop matches a callee name with no shape check — Set.prototype.delete resolves to the file's own delete() method, #11921's defect one level up #12358

Description

@yinlianghui

Observation class — recording only, no verdict asserted, no pm:queue. Unassigned. Found while performing the per-seam census #12138 asked for (PR #12356); deliberately not fixed there, because fixing it is the provenance problem #11921 owns.

Measured on origin/main @ 3ddad51b5c, reproduced after merging c312a562e3.

What I found

#11921 (PR #12137) fixed isReadCall matching a vocabulary callee name with no shape check — Array.prototype.find on a plain local array counted as a storage read. The fix is contradictsDriverReadShape, and it is applied at exactly one place:

if(DRIVER_READ_CALLEES.has(name)&&!contradictsDriverReadShape(node))returntrue;// ...if(depth>=MAX_READ_WRAPPER_DEPTH||seen.has(name))returnfalse;constbody=functionBodies.get(name);// ← the WRAPPER hop. No shape check, no receiver check.

The wrapper hop resolves a callee name against a flat same-file functionBodies index with no equivalent test. Any call whose calleeName happens to equal a function declared in that file is followed into that function's body, regardless of receiver.

The live instance, in packages/metadata-protocol/src/sys-metadata-repository.ts:

  • close() (line 1343) has try { w.terminate(); } catch { … }.
  • terminate resolves by name to the local const arrow at line 1246 — synchronous, void, in-memory only.
  • Its only call is self.watchers.delete(subscription), where private readonly watchers = new Set(...) (line 303). A Set.prototype.delete.
  • calleeName returns delete, and functionBodies.get('delete') returns this file's async delete(ref, opts) method (line 653) — whose engine.findOne('sys_metadata', …) sits inside a withTxn callback.

So a Set.delete on an in-memory watcher registry is one hop away from being read as a sys_metadata driver read.

Nothing is wrong today, and that is the whole point

The recognizer does not currently reach the fake read: the wrapper recursion's walkSameTickInclusive refuses to descend into the withTxn callback, so the walk stops before it gets there. The defect is latent, and it is armed by exactly the change #12138 was dispatched to consider.

Measured, with the walkAll probe #12138 describes:

recognizerread seams
today (walkSameTickInclusive)64
probe (walkAll)72
probe, with the delete wrapper hop refused70

The ablation removes exactly two seams — promoteDraftdropPromotedDraftRow (real: await this.delete(ref, …), the genuine method) and closeterminate (fake: the Set.delete) — and nothing else. One of the two seams the widening would have bought is invented.

Direction of the error

This one runs the unsafe way. Every other narrowness in that file under-counts; a fake seam is an invented member of the read-seam denominator that #5186, #6451, #9165, #8845 and #8901 are all quoted against. It is also silent: the seam prints in --list looking exactly like a real one, and its catch happens to be benign, so no verdict changes and nothing draws attention to it.

Why it is filed rather than fixed

Distinguishing this.delete(ref, opts) from someSet.delete(x) is a receiver/provenance question, which is #11921's problem and explicitly out of #12138's scope. Two cheap shapes exist and neither is obviously right without a measurement:

  • require the wrapper hop's receiver to be this / self / a bare identifier (would drop the Set.delete and keep this.delete);
  • give the wrapper hop a contradictsDriverReadShape-style argument test.

Both need a census over the whole scan root before anyone should believe them, exactly as #11921's did.

Dedupe performed

⚠️The prescribed REST channel was unavailable and this is declared rather than papered over: curl to api.github.com from this seat returns "GitHub access is not enabled for this session" and gh is absent — the condition already filed as #12123. Dedupe therefore ran through one bounded MCP list_issues call: 18 open finding issues, a non-empty control. None addresses isReadCall, the wrapper hop, functionBodies name resolution, or the read-seam population; the nearest neighbours are unrelated tooling/process findings (#12341 verify-lock discoverability, #12326 docs OG cards). A local grep over the gate file confirms contradictsDriverReadShape is referenced at the vocabulary check and nowhere near the wrapper hop.

Related


Generated by Claude Code

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions