fix(metadata-protocol): drop the invented-empty-registry swallow in global search

[huangyiirene]

Closes#11754

What was measured

• The seam, located by symbol (line numbers rot): searchAll in packages/metadata-protocol/src/protocol.ts read the host registry as (this.engine as any).registry?.getAllObjects?.() ?? []. An invented empty list made the whole sweep a silent no-op: zero hits, objectsScanned: 0, and a successful response.
• The fix(objectql): the roll-up summary index's registry read propagates, and a failed read is never cached as an empty index (#9154) #9284 precedent re-verified on origin/main at 7e83932621 before leaning on it: const objects: ServiceObject[] = this._registry.getAllObjects(); at packages/objectql/src/engine.ts 7448 / 10562 / 10805, and grep -c 'objects = []' over that file returns 0. The landed disposition is drop-both-halves-and-propagate.
• Honest frame: this is a Task, not a Bug. No live path is demonstrated reaching the seam and no test was shown vacuous. SchemaRegistry.getAllObjects() walks in-memory Maps with no throwing path, so the ?? [] could never fire on an outage — what the guards absorbed is the structural omission (a host registry that does not implement getAllObjects at all), which never throws and is invisible by construction. This closes the last unswept member of the invented-empty-registry family (finding(objectql): the delete-cascade path's two registry-read swallows are the #8895 shape one layer up — catch → return disables every referential guard at once, silently #9002, Measured set: five read seams answer a failed read from an empty accumulator with no log and no field saying the answer is incomplete #8896, finding(objectql): three more getAllObjects?.() ?? [] seams in plugin.ts invent an empty registry — one of them silently skips schema sync for every object at boot #9285/PR fix(objectql): plugin registry reads discriminate unreadable from empty — schema sync no longer skips every object silently at boot (#9285) #9682), on the ruled discriminate or propagate answer (ObjectQL.cascadeDeleteRelations fails OPEN: a failed dependents probe skips the restrict guard entirely, so a delete that should be refused succeeds silently #8895): a registry that cannot enumerate its objects is never truthfully "no objects" (ADR-0110 D3). No reproduction and no user-visible defect are claimed.

What changed

• packages/metadata-protocol/src/protocol.ts — one hunk at the seam: const allObjects = this.engine.registry.getAllObjects();. Both ?. and the ?? [] are gone; the as any cast went with them (registry is a declared member of MetadataHostEngine). No new error code and no new response field: at the REST door the omission surfaces through GET /search's existing catch → mapDataError path. This is an accept→reject flip on a public door for the broken-composition case only — a call that answered HTTP 200 with zero hits over an unenumerable registry now fails. The diff widens no public surface beyond that predicted flip.
• packages/metadata-protocol/src/protocol.read-seam-empty-accumulator.test.ts — four pins added beside the family's existing [Measured set: five read seams answer a failed read from an empty accumulator with no log and no field saying the answer is incomplete #8896] tests: the omission rejects (TypeError naming getAllObjects, and the data read was never issued), a registry-less engine rejects, a registry that truthfully enumerates "no objects" still resolves the successful empty response, and a blank query still short-circuits before the registry is consulted.
• .changeset/global-search-registry-propagate.md — patch, @objectstack/metadata-protocol.

What was deliberately NOT changed

• The import block at the top of protocol.ts (~L75) — untouched by construction; the diff is one hunk at the seam, ~9,800 lines away from PR fix(spec): re-export the three types the root entry's own inferred types mention (#11350) #11716's emitted-specifier pin region. No import was added or reordered.
• packages/cli/src/utils/schema-migrate.ts:329 — same spelling, but its docblock declares the degradation and its consumer is one advisory; examined and cleared by the filer (domain:cli).
• packages/objectql/src/plugin.ts:728 — the objectsRegistered start-log count, cleared explicitly by finding(objectql): three more getAllObjects?.() ?? [] seams in plugin.ts invent an empty registry — one of them silently skips schema sync for every object at boot #9285. Neither of finding(objectql): three more getAllObjects?.() ?? [] seams in plugin.ts invent an empty registry — one of them silently skips schema sync for every object at boot #9285 / fix(objectql): the roll-up summary index's registry read propagates, and a failed read is never cached as an empty index (#9154) #9284 / ObjectQL.cascadeDeleteRelations fails OPEN: a failed dependents probe skips the restrict guard entirely, so a delete that should be refused succeeds silently #8895 is addressed here; each remains as it was.
• No structured error is minted for the omission: the ruled disposition is propagation of the read's own failure, matching the engine-side precedent and the existing [Measured set: five read seams answer a failed read from an empty accumulator with no log and no field saying the answer is incomplete #8896] catch commentary ("the caller receives the read's own failure, envelope intact").

Test-double fallout, with counts

Predicted in advance from #9284's nine suites; measured here: 0 suites went red. All nine candidate suites referencing searchAll were enumerated and either run or read: metadata-protocol (4 suites — doubles all implement getAllObjects; the two orderby-vocabulary doubles without it feed only auditMetaItem), objectql (4 suites — real ObjectQL engines; the one minimal noTxEngine double calls only getDiscovery), rest (3 suites — either mock the protocol object itself or use a fake engine that implements getAllObjects), runtime (1 suite — mocks the protocol). No double was fixed because none was broken; no suite was skipped, disabled, or quarantined.

Verification (all at 583b3ed268, the branch head; exit codes captured before any pipe)

• pnpm --filter @objectstack/metadata-protocol exec vitest run --maxWorkers=2 — 139 files / 1913 tests passed, 0 failed (2 files / 10 tests pre-existing skips).
• Targeted downstream (after rebuilding @objectstack/metadata-protocol dist and confirming the fix reached it: grep -c 'registry.getAllObjects()' dist/index.js = 1, swallow spelling = 0): objectql 4 suites 78 passed; rest 3 suites 64 passed; runtime 1 suite 23 passed.
• Derived gate union (node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, change set taken by the script from merge base 7e8393262, derivation stamped at 583b3ed268): all 16 path-matched + 5 convention-triggered gates green by their own exit codes, including check:durability-log-level (its own verdict line: "66 read seam(s), none invents an unreported answer"), check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:nul-bytes ("scanned 6590 text file(s) … no raw ASCII control bytes").
• pnpm check:type-check-debt --re-measure after turbo run build --filter='./packages/*' --filter='./packages/*/*' (70/70 tasks): "32 ledger entr(ies) re-measured … none above its recorded number" — the new test code does not move metadata-protocol's frozen 63.
• pnpm lint (full repo eslint, not narrowed): exit 0.

Ablation, with numbers

Fix committed first; mutation and restore both proven on disk by anchored grep -cF counts; restore ran under trap … EXIT INT TERM.

• Direction predicted in advance: the two omission pins go red with a resolved invented-empty response; the two controls and all [Measured set: five read seams answer a failed read from an empty accumulator with no log and no field saying the answer is incomplete #8896] tests stay green.
• Mutation leg: swallow spelling restored (swallow-count=1, fixed-count=0 on disk). vitest run src/protocol.read-seam-empty-accumulator.test.ts → exit 1, 2 failed / 12 passed, both failures the exact pre-fix shape: expected a rejection, but the call resolved with {"query":"Acme","hits":[],"totalObjects":0,"totalHits":0,"truncated":false}.
• Restore leg: swallow-count=0, fixed-count=1, git status --porcelain empty.
• No rebuild was needed for either ablation leg, and that claim is itself measured: the suite imports ./protocol.js relative (vitest resolves it to src/protocol.ts), and the package's full suite — new pins included — passed beforepackages/metadata-protocol/dist existed in this fresh worktree, which is only possible if the tests read src, not dist.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata-protocol, touching 1 documentable anchor(s).

⛔ 1 release-owned page(s) name something this change touched. These are read-only:

• content/docs/releases/v17.mdx(via searchAll (symbol))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 45 of 222 client-bound route-ledger rows — the other 177 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run: node scripts/docs-audit/affected-docs.mjs --bridge-coverage

Coarse fallback — 7 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json e43b18fd9413b5774952eda5b852a54ef423ce2c → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 37f77283ae1eb675af5361efee9f9f552de83252 — the merge of head 583b3ed268513771935440a62c4ae3421cbf4e43 into base e43b18fd9413b5774952eda5b852a54ef423ce2c, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 37f77283ae1eb675af5361efee9f9f552de83252 && git checkout 37f77283ae1eb675af5361efee9f9f552de83252
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin e43b18fd9413b5774952eda5b852a54ef423ce2c 583b3ed268513771935440a62c4ae3421cbf4e43 && git checkout -B drift-repro e43b18fd9413b5774952eda5b852a54ef423ce2c && git merge --no-ff 583b3ed268513771935440a62c4ae3421cbf4e43
node scripts/docs-audit/affected-docs.mjs --json e43b18fd9413b5774952eda5b852a54ef423ce2c

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs e43b18fd9413b5774952eda5b852a54ef423ce2c → pass the list as
args.docs, on the commit named under Which tree this was computed on.