Follow-up from #13407 (not fixed there — materially larger, separately-scoped change with its own package/verification discipline; the card's own repro and pin go through GET /meta/view?object= → getMetaItems, not this exit).
Background. The hydrateExpandedViewItems doc comment (protocol.ts) has long named two independent object-bound readers: the REST route (GET /meta/view?object=), which reads through ObjectStackProtocolImplementation.getMetaItems (sys_metadata DB rows, org/environment-scoped), and MetadataManager.getViewsByObject() (packages/metadata/src/metadata-manager.ts:~1583), which reads this.list('view') — MetadataManager's own loader-based registry (this.registry, populated via registerLoader/readList), a completely separate store from sys_metadata/the ObjectQL SchemaRegistry.
What #13407 fixed, and why it doesn't reach this exit. #13407 made getMetaItems expand a runtime-authored aggregated view container inline, into that request's own response, for org-scoped and environment-scoped reads — but only inside protocol.ts's getMetaItems. MetadataManager.getViewsByObject() never calls getMetaItems and has no equivalent inline-expansion step, so a runtime-authored container that #13407 now makes visible via GET /meta/view?object= can still answer empty when read via getViewsByObject() directly (whatever internal/SDK caller uses that entry point rather than the REST route).
Suggested next step: determine whether MetadataManager's dbLoader (registered in its constructor) already surfaces sys_metadata overlay rows the same way getMetaItems's overlays merge does, and if so add the equivalent registry-free inline expansion there (reusing expandRuntimeViewContainer's logic/shape from protocol.ts if these two packages can share it, or a packages/metadata-local equivalent). This is a packages/metadata change with its own test suite — out of packages/metadata-protocol's lane and #13407's PR.
Related: #13407, #7163, #7736.
Follow-up from #13407 (not fixed there — materially larger, separately-scoped change with its own package/verification discipline; the card's own repro and pin go through
GET /meta/view?object=→getMetaItems, not this exit).Background. The
hydrateExpandedViewItemsdoc comment (protocol.ts) has long named two independent object-bound readers: the REST route (GET /meta/view?object=), which reads throughObjectStackProtocolImplementation.getMetaItems(sys_metadataDB rows, org/environment-scoped), andMetadataManager.getViewsByObject()(packages/metadata/src/metadata-manager.ts:~1583), which readsthis.list('view')—MetadataManager's own loader-based registry (this.registry, populated viaregisterLoader/readList), a completely separate store fromsys_metadata/the ObjectQL SchemaRegistry.What #13407 fixed, and why it doesn't reach this exit. #13407 made
getMetaItemsexpand a runtime-authored aggregated view container inline, into that request's own response, for org-scoped and environment-scoped reads — but only insideprotocol.ts'sgetMetaItems.MetadataManager.getViewsByObject()never callsgetMetaItemsand has no equivalent inline-expansion step, so a runtime-authored container that #13407 now makes visible viaGET /meta/view?object=can still answer empty when read viagetViewsByObject()directly (whatever internal/SDK caller uses that entry point rather than the REST route).Suggested next step: determine whether
MetadataManager'sdbLoader(registered in its constructor) already surfacessys_metadataoverlay rows the same waygetMetaItems'soverlaysmerge does, and if so add the equivalent registry-free inline expansion there (reusingexpandRuntimeViewContainer's logic/shape fromprotocol.tsif these two packages can share it, or apackages/metadata-local equivalent). This is apackages/metadatachange with its own test suite — out ofpackages/metadata-protocol's lane and #13407's PR.Related: #13407, #7163, #7736.