Found while executing #15034 (PR #15619). The file is fenced for that card (protocol.ts belongs to another seat, and PR #15592 is open on it), so this is filed rather than edited.
The enumeration, and the count
packages/metadata-protocol/src/protocol.ts, the [#14683] gate docblock above getMetaItems' organizationIdForMetaRead call (around :6928-:6942 on origin/main at ba426b0f091), lists the callers that already gate:
packages/rest's GET /meta/:type list door — the only door that both gates and reaches this method — computes organizationIdForMetaRead(canonicalMetaUrlType(req.params.type), ctx?.tenantId) [...]- the search sweep's page read below gates on
'page' [...]
- the four remaining
organizationIdForMetaRead call sites in rest-server.ts (/layers, the by-name read, /history, /diff) reach getMetaItemLayered / getMetaItem / historyMetaItem / diffMetaItem — never this method
Measured, same ref, git show origin/main:packages/rest/src/rest-server.ts | grep -n organizationIdForMetaRead — there are six call sites, not five:
:3353 /meta/:type/:name/layers -> getMetaItemLayered listed
:4808 /meta/diagnostics ?type= -> getMetaItems ABSENT FROM THE ENUMERATION
:5079 GET /meta/:type list door -> getMetaItems named as "the only door"
:5968 by-name read -> getMetaItem listed
:6824 /history -> historyMetaItem listed
:7392 /diff -> diffMetaItem listed
1 named + 4 remaining = 5. The diagnostics ?type= door is the sixth, and it both gates and reaches getMetaItems — so "the only door that both gates and reaches this method" is false, and "the four remaining ... never reach this method" silently excludes a site that does.
⭐ Why it was missed, which is the interesting half
The diagnostics door does not call getMetaItems directly. It calls getMetaDiagnostics, which loops getMetaItems({ type: t, organizationId }) per swept type. A grep for doors invoking getMetaItems therefore misses it — the same reason the population statement one method over (getMetaItem's "FOUR, across two files") warns that its own first enumeration "named only the first file and was wrong".
⚠️ And getMetaDiagnostics is not a member of MetadataProtocol at all — not required, not optional — so it is reached through a runtime cast and 501s when a kernel does not implement it. The transitive path runs through an undeclared extension, which is precisely the kind of edge a caller census has to be told about rather than derive.
Why it matters
The enumeration is the artefact #14683 offers as the proof that its change is a no-op for every already-gating caller. A caller absent from it is a caller whose idempotence nobody stated. (It IS a no-op — PR #15619 measured it: both sites fold the identical string, and swapping the door's predicate for a raw tenant id leaves the pin 30/30 green. The conclusion holds; the enumeration backing it does not.)
What is asked
Add the diagnostics ?type= site to the enumeration, note that it reaches this method transitively through getMetaDiagnostics, and correct the "only door" clause.
⚠️ Adjacency
PR #15592 is open and edits the sibling docblock's raw-organization caller enumeration in this same file. Whichever lands second inherits the other's text — re-read on the merged ref rather than on this card.
Found while executing #15034 (PR #15619). The file is fenced for that card (
protocol.tsbelongs to another seat, and PR #15592 is open on it), so this is filed rather than edited.The enumeration, and the count
packages/metadata-protocol/src/protocol.ts, the[#14683]gate docblock abovegetMetaItems'organizationIdForMetaReadcall (around:6928-:6942onorigin/mainatba426b0f091), lists the callers that already gate:Measured, same ref,
git show origin/main:packages/rest/src/rest-server.ts | grep -n organizationIdForMetaRead— there are six call sites, not five:1 named + 4 remaining = 5. The diagnostics
?type=door is the sixth, and it both gates and reachesgetMetaItems— so "the only door that both gates and reaches this method" is false, and "the four remaining ... never reach this method" silently excludes a site that does.⭐ Why it was missed, which is the interesting half
The diagnostics door does not call
getMetaItemsdirectly. It callsgetMetaDiagnostics, which loopsgetMetaItems({ type: t, organizationId })per swept type. A grep for doors invokinggetMetaItemstherefore misses it — the same reason the population statement one method over (getMetaItem's "FOUR, across two files") warns that its own first enumeration "named only the first file and was wrong".getMetaDiagnosticsis not a member ofMetadataProtocolat all — not required, not optional — so it is reached through a runtime cast and 501s when a kernel does not implement it. The transitive path runs through an undeclared extension, which is precisely the kind of edge a caller census has to be told about rather than derive.Why it matters
The enumeration is the artefact #14683 offers as the proof that its change is a no-op for every already-gating caller. A caller absent from it is a caller whose idempotence nobody stated. (It IS a no-op — PR #15619 measured it: both sites fold the identical string, and swapping the door's predicate for a raw tenant id leaves the pin 30/30 green. The conclusion holds; the enumeration backing it does not.)
What is asked
Add the diagnostics
?type=site to the enumeration, note that it reaches this method transitively throughgetMetaDiagnostics, and correct the "only door" clause.PR #15592 is open and edits the sibling docblock's raw-organization caller enumeration in this same file. Whichever lands second inherits the other's text — re-read on the merged ref rather than on this card.