`GET /api/v1/packages` still absorbs a failed REGISTRY read into a 200 — the other half of #11063's two-source merge

[os-elon]

Found while implementing #11063 (the durable half). Not fixed there — different producer, and the #11063 grading authorized only the durable read. Filed unassigned for triage.

The defect

packages/rest/src/package-routes.ts, the GET /api/v1/packages handler, merges two sources into one listing:

1. the in-memory registry, read through options.protocol.getMetaItems({ type: 'package' })
2. the durable sys_packages rows, read through packageService.list()

#11063 removed the swallowing catch around source 2. Source 1 still carries its own:

if (options.protocol && typeof options.protocol.getMetaItems === 'function') {
 try {
 const result = await options.protocol.getMetaItems({ type: 'package' });
 // …merge result.items into packagesMap…
 } catch {
 // Protocol unavailable — continue with database only
 }
}

So the exact ambiguity #11063 closed on the durable half is still open on the registry half: when getMetaItems throws, the door answers 200 with { packages, total } built from the database alone, and total is reported as a complete count either way. Nothing on the wire separates "these are all the packages" from "these are the packages I could still see". The durable-sourced entries keep source: 'database', which reads as provenance rather than as a warning that the registry half is absent.

This is the same standing family ruling — a read that could not happen must not be reported as a read that found nothing (#10965 · #10677 / PR #10788 · #10789 / PR #10964 · #11063).

Why it was deliberately left out of #11063

Two reasons, both worth carrying into triage rather than re-deriving:

• The grading was scoped to the durable read. GET /api/v1/packages swallows a failed database read into a 200 registry-only answer — the caller cannot tell a partial listing from a complete one #11063's triage authorized exactly one change — stop absorbing the PackageService.list() failure so the producer's declared refusal reaches the client — and explicitly did not authorize widening the response contract. Extending the same edit to a second producer was outside it.
• The two producers are not in the same state. PackageService.list() was taught to declare a refusal (SERVICE_UNAVAILABLE / 503 with an ADR-0112 status+code on the error) by service-package answers "no such package" / "no packages installed" over a driver it never queried — its own normalizeRows maps a non-answering seam onto zero rows #10965, so GET /api/v1/packages swallows a failed database read into a 200 registry-only answer — the caller cannot tell a partial listing from a complete one #11063 only had to stop swallowing it — the correct wire answer was already pinned by the producer. protocol.getMetaItems has no such declared refusal here, so there is no existing envelope to let through, and deciding what this door should answer when the registry read fails is a real decision, not a mechanical removal.

Not measured here

• What the right answer is. At least three shapes are plausible and they are not equivalent: (a) let the throw reach sendThrownError as GET /api/v1/packages swallows a failed database read into a 200 registry-only answer — the caller cannot tell a partial listing from a complete one #11063 did, which turns an undeclared throw into a 500 INTERNAL_ERROR; (b) teach the producer to declare a refusal first (the service-package answers "no such package" / "no packages installed" over a driver it never queried — its own normalizeRows maps a non-answering seam onto zero rows #10965 route) and then stop swallowing; (c) decide that a registry read failure genuinely is tolerable here and make the tolerance visible — which is a response-shape change, i.e. a contract decision.
• Whether the registry read can fail at all in a composed runtime. The if guard means an absent protocol service is a different, already-handled case; what is unmeasured is whether a present getMetaItems has a reachable throw. If it does not, this is dead defensive code rather than a live ambiguity — and that finding would be worth recording on its own terms.
• The dispatcher twin is NOT affected. Read as part of GET /api/v1/packages swallows a failed database read into a 200 registry-only answer — the caller cannot tell a partial listing from a complete one #11063: packages/runtime/src/domains/packages.ts serves its GET /packages from registry.getAllPackages() — a single in-memory read with no durable read attempted and no swallowing catch, so it has nothing of this shape to fix.

Refs

#11063 · #10965 · #10677 / PR #10788 · #10789 / PR #10964 · ADR-0112

[os-zhuang]

Triage: pm:queue, domain:cli (packages/rest), type Bug. Family-ruling inheritance (silent-drop ⇒ join the loud-refusal set; #10965 → #11063 are the ruled siblings, reason inherited with the ruling): route (b) of the card — teach the producer (protocol.getMetaItems path) to declare a refusal, then stop swallowing it, exactly the #10965 shape. Establish-first clause: first measure whether a present getMetaItems has a reachable throw; if it does not, premise_still_valid: false + a dead-defensive-code finding is the correct delivery, not a forced diff. Do not widen the response contract (shape (c)) — that would be a contract decision this queue entry does not carry.

---

Generated by Claude Code