Found while producing the boot-path reading for #13331. Filed unassigned; recording only.
The drift
packages/objectql/src/metadata-facade.ts:67-79 (class docblock):
MetadataFacade
Provides a clean, injectable interface over SchemaRegistry.
Registered as the 'metadata' kernel service to eliminate
downstream packages needing to manually wrap SchemaRegistry.
packages/objectql/src/metadata-facade.ts:134-136, in the same file, in registerObjectBothPlaces' header:
Dormant in-tree only because nothing on main installs a MetadataFacade into the
metadata slot — but the class is exported from this package's root and
core entrypoints, so a downstream host got the split.
The two statements contradict each other and the second one is the true one.
Measured
ctx.registerService('metadata', ...) has exactly one non-test site in the tree, and it is not this class:
packages/metadata/src/plugin.ts:353: ctx.registerService('metadata', this.manager);
The variable-key registrations that a literal-key query cannot see were swept separately (registerService( with a non-literal first argument); the only ones that reach the metadata slot are the kernel's own core-fallback pre-injection, ObjectKernel.preInjectCoreFallbacks() (packages/core/src/kernel.ts:270) and its safety-net twin in validateSystemRequirements() (:303), both of which register CORE_FALLBACK_FACTORIES.metadata = createMemoryMetadata, not a MetadataFacade.
Booting a real ObjectKernel with no MetadataPlugin and reading getService('metadata') returns the memory fallback's exact member list, confirming it directly:
_serviceName : metadata
__serviceInfo.status : degraded
shape keys : __serviceInfo,_serviceName,register,registerInMemory,get,
list,unregister,exists,listNames,getObject,listObjects
Why it is worth fixing rather than leaving
This line is load-bearing misinformation, not a cosmetic staleness: it is the most likely source of #13331's framing, which asserted as its premise that "the runtime dispatcher/domain facade" registers the 'metadata' service and imagined the fix as adding a delegate method to that facade. A reader grepping for who fills the slot finds this docblock, believes it, and stops. The triage seat on #13331 independently found the premise did not hold up.
Suggested repair
Correct the class docblock to say what the :134 header already says — the class is exported for downstream hosts and is not installed into the metadata slot by anything in this repo. Keep the two statements in one voice so the next reader cannot pick the wrong one.
Related: #13331 (the card whose premise this line likely produced).
Found while producing the boot-path reading for #13331. Filed unassigned; recording only.
The drift
packages/objectql/src/metadata-facade.ts:67-79(class docblock):packages/objectql/src/metadata-facade.ts:134-136, in the same file, inregisterObjectBothPlaces' header:The two statements contradict each other and the second one is the true one.
Measured
ctx.registerService('metadata', ...)has exactly one non-test site in the tree, and it is not this class:The variable-key registrations that a literal-key query cannot see were swept separately (
registerService(with a non-literal first argument); the only ones that reach themetadataslot are the kernel's own core-fallback pre-injection,ObjectKernel.preInjectCoreFallbacks()(packages/core/src/kernel.ts:270) and its safety-net twin invalidateSystemRequirements()(:303), both of which registerCORE_FALLBACK_FACTORIES.metadata=createMemoryMetadata, not aMetadataFacade.Booting a real
ObjectKernelwith noMetadataPluginand readinggetService('metadata')returns the memory fallback's exact member list, confirming it directly:Why it is worth fixing rather than leaving
This line is load-bearing misinformation, not a cosmetic staleness: it is the most likely source of #13331's framing, which asserted as its premise that "the runtime dispatcher/domain facade" registers the
'metadata'service and imagined the fix as adding a delegate method to that facade. A reader grepping for who fills the slot finds this docblock, believes it, and stops. The triage seat on #13331 independently found the premise did not hold up.Suggested repair
Correct the class docblock to say what the
:134header already says — the class is exported for downstream hosts and is not installed into themetadataslot by anything in this repo. Keep the two statements in one voice so the next reader cannot pick the wrong one.Related: #13331 (the card whose premise this line likely produced).