Skip to content

unique-ids-must-be-unique-in-pattern conflates two contracts #3095

Description

@YoofiTT96

unique-ids-must-be-unique-in-pattern collects node ids, relationship ids and interface ids into one set and reports any id that appears twice. Two different contracts share that set.

Contract Reason Applies to
Selectability a decision picks an alternative by unique-id, so two alternatives of one entry need different ids node and relationship ids
Coexistence two ids must differ if both can appear in one architecture every pair that can appear together

The two contracts disagree about alternatives of one prefixItems entry. Selectability says the ids must differ. Coexistence says they may repeat, because only one alternative is ever built. Both are correct about their own harm.

The set records that an id was seen. It does not record where. So the rule cannot tell which contract a given pair belongs to, and the answer depends on the order of the three sweeps.

#3059 added the coexistence logic for interface ids only, and left node and relationship ids on the flat sweep. That works for every shape in this repository, but it is a special case attached to the wrong sweep rather than a stated rule.

Proposal. Split the function into two named checks inside the same Spectral rule. Coexistence groups every id by prefixItems entry, separates the entry's own properties from its alternatives, and compares only declarations that can appear together. Selectability compares the alternatives' node ids within an entry, and their relationship ids.

No new rule code, no message changes, no change to the published rule list.

Known behaviour change. One shape becomes legal: an entry whose alternatives use one name for a node and for an interface, for example oneOf: [ postgres exposing "db", node "db" ]. Both architectures that entry can produce are valid today. #3059 rejects the pattern deliberately, on the contract that a name belongs to one kind of thing, recorded in PATTERN-DECISIONS.md. Change that contract before adopting this proposal, or keep the rejection and make it explicit in the new checks.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions