feat(objectql): opt-in sys_metadata hydration for isolated project kernels#1826
Merged
Conversation
…rnels Boot Phase-2 hydration (restoreMetadataFromDb → loadMetaFromDb, which registers objects WITH their fields into the SchemaRegistry) is gated on `environmentId === undefined`. That gate assumes every project kernel sources metadata from a remote artifact / control-plane proxy and has no local sys_metadata. It's untrue for an isolated, proxy-free project kernel that persists its OWN sys_metadata locally (the cloud single-env tenant runtime on Turso): objects CREATED AT RUNTIME there — absent from the boot artifact manifest — never re-enter the registry after a restart, so `registry.getObject(name)` returns nothing for them and every registry consumer silently degrades (notably the engine.find unknown-$select guard, which then lets an unknown projected column zero the result set). Add an explicit `hydrateMetadataFromDb` plugin option (default false, so the control-plane/proxy path is untouched). When set, hydration runs even with `environmentId` defined. Safe because each engine owns its registry instance (no cross-kernel leakage — the historical process-wide singleton is gone, see engine.ts:274) and loadMetaFromDb already tolerates a missing table. The cloud artifact-kernel-factory — proxy-free, local sys_metadata, isolated registry — opts in. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Boot Phase-2 hydration (
restoreMetadataFromDb→loadMetaFromDb, which registers objects with their fields into theSchemaRegistry) is gated onenvironmentId === undefined(plugin.ts). That gate assumes every project kernel sources metadata from a remote artifact / control-plane proxy and has no localsys_metadata.That's untrue for an isolated, proxy-free project kernel that persists its OWN
sys_metadatalocally — the cloud single-env tenant runtime (Turso). There, objects created at runtime (e.g. via AI Studio) are not in the boot artifact manifest, so after a container restart they never re-enter the registry.registry.getObject(name)then returns nothing for them, and every registry consumer silently degrades — most visibly theengine.find()unknown-$selectguard, which can no longer drop a phantom projected column and lets it zero the whole result set.Confirmed against a live env (cloud#290):
productwas created at runtime, its fields are stored inline insys_metadata, yet the guard never fired because the object wasn't in the engine registry after redeploy.Fix
Add an explicit
hydrateMetadataFromDbplugin option (defaultfalse, so the control-plane/proxy path is unchanged). When set, Phase-2 hydration runs even withenvironmentIddefined.Safe because:
SchemaRegistryinstance — the historical process-wide singleton is gone (engine.ts:274), so there's no cross-kernel leakage.loadMetaFromDbalready tolerates a missingsys_metadatatable (graceful no-op).The cloud
artifact-kernel-factory— documented as proxy-free with localsys_metadataand an isolated registry — opts in (separate cloud PR + SHA bump).Tests
plugin.integration.test.ts(+2):environmentIdset) without the opt-in does NOT read localsys_metadataand does NOT register the runtime object (current behavior preserved);hydrateMetadataFromDb: trueit hydrates andregistry.getObject('product').fieldscontains the inline field (fails without the gate change).Full
plugin.integration.test.ts: 25 pass. Package builds + typechecks clean.Tracks objectstack-ai/cloud#290.
🤖 Generated with Claude Code