Skip to content

Add full patternProperties support to schema compatibility validation #105

Description

@aviator5

Context

During review of PR #104, CodeRabbit pointed out that validate_closed_descendant_branches can falsely report an ancestor property as orphaned when a closed descendant branch (additionalProperties: false) permits that property via patternProperties instead of explicit properties.

That observation is valid JSON Schema semantics, but a narrow exception in the orphan check would be incomplete: the current OP#12 compatibility checker does not model patternProperties as a first-class part of effective schema compatibility.

Current behavior

gts/src/schema_compat.rs primarily extracts and compares:

  • properties
  • required
  • additionalProperties
  • allOf composition

It does not generally account for patternProperties when determining whether derived schemas preserve or loosen ancestor constraints.

Problem

A descendant schema may be valid under JSON Schema while being incorrectly rejected by the compatibility checker, for example when an ancestor property such as userId is covered by a descendant branch like:

{
  "additionalProperties": false,
  "patternProperties": {
    "^user": { "type": "string" }
  }
}

At the same time, handling only this closed-branch orphan case would create partial semantics: other compatibility questions involving patternProperties would remain undefined or inconsistent.

Desired outcome

Design and implement full patternProperties support for GTS schema compatibility validation, or explicitly document it as unsupported if the spec should not require it yet.

Potential scope:

  • Include patternProperties in the effective schema model where appropriate.
  • Decide how patternProperties interacts with explicit properties and additionalProperties: false in OP#12 compatibility checks.
  • Avoid false positives in closed descendant branch validation when an ancestor property is matched by a descendant pattern.
  • Decide how conservative the checker should be for regex subset/equivalence questions.
  • Add focused unit tests and, if applicable, gts-spec conformance coverage.

Related

PR #104 review comment: #104 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions