You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ADR-0048 (package-id as route/identity key) landed across #1810, #1813, #1816, #1819, #1822 (+ objectui #1708, #1711). Single-item reads (?package=), the Studio editor, and the runtime render surface (dashboard/report/page/doc via prefer-local) now resolve same-name collisions to the correct package — for pure-artifact items (the marketplace default).
The remaining gap
A package-less, env-wide customization overlay (a sys_metadata row with package_id NULL) for a name that collides across two installed packages is inherently ambiguous and cannot be disambiguated today.
Root cause is schema-level: sys_metadata has a UNIQUE index on (type, name, organization_id) (idx_sys_metadata_overlay_active / …_draft), not including package_id. So:
At most ONE active overlay row can exist per (type, name, org).
restoreMetadataFromDb rehydrates that row under the bare registry key (no package), where it takes ADR-0005 overlay precedence over BOTH packages' composite artifacts.
A getMetaItem(type, name, packageId) whose overlay query misses the scoped package_id falls back to the package-less row and serves the same overlay for every package.
Concretely: showcase ships page/home, studio ships page/home; an admin customizes one → the env overlay shadows both, and ?package= can't tell them apart.
Proposed direction (needs an ADR / design decision)
Make overlays package-aware:
Add package_id to the overlay uniqueness key: UNIQUE(type, name, organization_id, package_id) (migration + backfill).
Context
ADR-0048 (package-id as route/identity key) landed across #1810, #1813, #1816, #1819, #1822 (+ objectui #1708, #1711). Single-item reads (
?package=), the Studio editor, and the runtime render surface (dashboard/report/page/doc via prefer-local) now resolve same-name collisions to the correct package — for pure-artifact items (the marketplace default).The remaining gap
A package-less, env-wide customization overlay (a
sys_metadatarow withpackage_idNULL) for a name that collides across two installed packages is inherently ambiguous and cannot be disambiguated today.Root cause is schema-level:
sys_metadatahas a UNIQUE index on(type, name, organization_id)(idx_sys_metadata_overlay_active/…_draft), not includingpackage_id. So:(type, name, org).restoreMetadataFromDbrehydrates that row under the bare registry key (no package), where it takes ADR-0005 overlay precedence over BOTH packages' composite artifacts.getMetaItem(type, name, packageId)whose overlay query misses the scopedpackage_idfalls back to the package-less row and serves the same overlay for every package.Concretely: showcase ships
page/home, studio shipspage/home; an admin customizes one → the env overlay shadows both, and?package=can't tell them apart.Proposed direction (needs an ADR / design decision)
Make overlays package-aware:
package_idto the overlay uniqueness key:UNIQUE(type, name, organization_id, package_id)(migration + backfill).saveMetaItembinds the overlay to the edited item's owning package (the Studio editor already threads?package=since docs(references): regenerate flow reference for the map node type #1711 — the write path needs to persist it).restoreMetadataFromDbregisters package-bound overlays under the composite key, not bare.protocol.getMetaItem/getMetaItemLayeredoverlay queries already preferpackage_id-scoped rows (ADR-0048); the package-less fallback should only apply to genuinely package-less (legacy/global) overlays.Open questions
Acceptance
page/home, each with its own overlay, resolve independently via?package=and in the Studio layered/editor view.Out of scope: pure-artifact collisions (already fixed in #1822).