[finding] getMetaDiagnostics scannedTypes still overstates the swept set when a type is benignly skipped — no payload field lets a caller detect partial coverage #8924

Restart-when: any PR touches getMetaDiagnostics in packages/metadata-protocol/src/protocol.ts

Filed unassigned by the dev seat on #8855 (PR #8923) to record a residue that card deliberately did not close, so it is not lost when #8855 closes. Observation-class: no user-visible failure is claimed today.

What #8923 closed, and what it left

#8855's ruling was "propagate the 503, no surface change", and #8923 implements exactly that: getMetaDiagnostics's per-type catch now rethrows the metadata-store 503 unchanged and still skips the type for every other failure. The outage case is therefore loud now.

The residue is the benign half of that same catch. When a type is genuinely not listable in this kernel scope, the sweep skips it and:

• scannedTypes is targetTypes.length, fixed before the loop and never decremented on continue, so the response asserts "I scanned N types" having scanned fewer;
• the discrepancy is not derivable by the caller — Object.keys(stats).length is only a lower bound, because a type that reads fine but holds no items also produces a stats entry with count: 0. fix(metadata-protocol): propagate the metadata-store 503 out of getMetaDiagnostics (#8855) #8923's own pin measures both spellings of that: 26 stat keys for a clean all-empty sweep, 25 when one type is skipped, with scannedTypes reporting 26 in both.

So there is still no field in the payload from which a client can compute "some of this is missing".

Why it was not fixed under #8855

Triage ruled (5302846257) that a per-type degradation marker in the payload is a public-surface addition, to be escalated rather than added under that card. #8923 did not conclude the marker was needed — the harm #8855 actually named (an unreadable store published as "0 problems") is closed by the 503 propagation without one. This card is the place to decide whether the benign-skip half deserves the same treatment, not a re-litigation of that ruling.

What a taker should establish first

The honest open question is whether this is worth any surface at all:

1. Is the benign skip reachable in practice? fix(metadata-protocol): propagate the metadata-store 503 out of getMetaDiagnostics (#8855) #8923's pin constructs it deliberately (a registry whose listing throws for one type). Whether a real kernel scope produces it — and for which types — was not measured. If it is unreachable, scannedTypes never actually lies and the right answer is a comment, not a field.
2. If it is reachable, the options are roughly: decrement scannedTypes on skip (no new field, but silently changes an existing number's meaning); add a skippedTypes list (new public surface, needs the escalation the ruling describes); or leave it and document that scannedTypes is an intent count.

Startup-focus applies: no consumer is known to read scannedTypes for coverage today — the Studio directory page reads stats for tile counts. Establish a reader before adding surface.

Explicitly not this card

The organizationId observation on #8855 (the REST handler forwards type/severity/packageId but no organizationId) belongs to the #8805 tenant-scoping thread and was left unmeasured by #8923 per the ruling. It is named here only so nobody re-derives it as new.

Backlinks: #8855, #8923.

Generated by Claude Code

Generated by Claude Code