Skip to content

finding(metadata-protocol): the runtime save door accepts a view container whose body name contradicts its row name and registers it under both keys; the two source registrars refuse the same document #21412

Description

@objectstack-fleet

Filing gate: ① a defect, class (b): two doors over one contract disagree. reach: measured once at the save door, the protocol seam REST PUT /meta/view/:name and the dispatcher door both call. The measurement used the stub engine of view-container-runtime-expansion.test.ts, not HTTP. Filed by domain:spec seat 2 (session_01YDt3PzwfrkuFzUBF89WPmM, seat post #18549), from the #20301 stage-2 os-dev report 5953000865 (out-of-scope finding 1). ⛔ Filed bare: routing and grading are triage's. ⛔ Not a claim.

Who acts on it: the lane that owns packages/metadata-protocol, after triage routes it.

Dedupe: the 1,000 most recently updated issues and PRs here, open and closed (down to #2714), were listed by REST and grepped for viewContainerNameRefusal, divergent … name, hydrateOverlayIntoRegistry, mergePackageAwareOverlay and view-container-divergent. That gave 1 hit: PR #21369 (closed, os generate; it reads the source registrars, not this door). As a control, view container hits 9.

Measured (os-dev report 5953000865, at main 1d0600bf66)

  • The probe: saveMetaItem({ type: 'view', name: 'crm_lead', item: { name: 'lead_views', list: { … } } }).
    • It is accepted, with no error.
    • The sys_metadata row is crm_lead, but the stored body's name is lead_views.
    • The registry keys are lead_views and crm_lead.default: one document filed under two keys.
  • Why:
    • metadata-protocol normalizeViewMetadata (protocol.ts:1227) stamps the save name only when the body has none, and keeps an authored one.
    • hydrateOverlayIntoRegistry (:15990) and mergePackageAwareOverlay (:1835) then key the overlay by body.name.
  • The two source registrars refuse this same document with VALIDATION_ERROR / 400: objectql viewContainerNameRefusal (packages/objectql/src/view-container-name-refusal.ts) and the artifact door's assertMetadataRegisterContract. They do so under the maintainer's ruling of 2026-09-03 (PR fix(objectql): the boot loop refuses a view container whose name disagrees with its derived object key (#14666) #15319, direction 2 adopted: refuse the divergence; direction 3, forbidding the key in spec, refused). The runtime save door is the third door, and it does not.

The fix direction (⛔ not a ruling)

The runtime save door refuses a container body name that differs from the save name, through viewContainerNameRefusal's judgement and words (one judge, not a second rule), with a pin. A body name equal to the save name, or absent (the door stamps it), keeps passing.

Dedupe words: view container name divergent runtime door · saveMetaItem container body name row name mismatch · hydrateOverlayIntoRegistry body name key · viewContainerNameRefusal metadata door


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:apiThe API a customer can call, and integrations — REST, connectors, webhooks, jobsbugSomething isn't workingdomain:enginepriority:p2Medium: important, M3

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions