Skip to content

hydrateOverlayIntoRegistry mints registry entries under the RAW type with no fold and no assertion — the last unfolded seam of the objects tolerance family #9111

Description

@os-zhuang

Backlink: #8862 (surfaced while implementing its removal half, PR #9110). ⚠️ Reachability NOT measured — filing plainly rather than grading it, per the discipline #8820 and #8862 both landed on.

What was measured

packages/metadata-protocol/src/protocol.ts, hydrateOverlayIntoRegistry:

private hydrateOverlayIntoRegistry(
    type: string,
    data: unknown,
    options: { packageId?: string | null; organizationId: string | null },
): boolean {
    
    const artifact = this.lookupArtifactItem(type, (data as any).name, options.packageId ?? undefined);
    registry.registerItem(type, mergeArtifactProtection(data, artifact), 'name' as any);

The spelling handed in is the spelling the registry entry is minted under — the same consuming shape #8862 was filed about, one helper over. There is no fold and no assertion at this seam; the parameter is a bare type: string.

Why it surfaced now

#8862 removed the four 'objects' tolerance limbs. That changes where an unfolded plural lands in applyRegistryWriteThrough: it no longer takes the object branch, so on an unscoped kernel it now falls through to this helper. The removal is still correct and its stated win holds (the object is not registered, so assertObjectRegistered fails CLOSED — a loud error replacing a silent one), but the ruling's shorthand "does not register" is not literally true, and this seam is why. That is recorded in PR #9110's body and in the code comments rather than left implicit.

To be clear about what this issue is and is not:

Suggested disposition

Measure reachability across every caller first (including the read-side hydration paths, not just the write-through). Then, if dormant, the cheap structural close is to make the contract enforced rather than assumed — fold at the helper, or assert the canonical form and fail loudly — instead of leaving a fourth card to rediscover it. canonicalMetaType's header is the standing argument for why a tolerant or silently-trusting lookup below a folding boundary is the wrong shape.

Related: #9009 (getEffectiveLock's overlay limb queries the raw type) — same family, different seam, also filed from this card's lineage.

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions