Skip to content

fix: restore two schema checks dropped by #64's conflict resolution#65

Draft
macanderson wants to merge 1 commit into
mainfrom
fix-dropped-schema-checks
Draft

fix: restore two schema checks dropped by #64's conflict resolution#65
macanderson wants to merge 1 commit into
mainfrom
fix-dropped-schema-checks

Conversation

@macanderson

Copy link
Copy Markdown
Owner

Follow-up to #64. main is currently serving a stale schema, and the check that would catch it was deleted in the same merge.

What happened

#64's conflict resolution kept its own schema/validate-examples.py wholesale, discarding both checks #63 had added to that file on main:

Check Added by Purpose
reference-serialized vector validation #63 (issue #54) Validates the Rust serializer's own minimal output against the schema — the half curated examples cannot catch
$id + served-copy byte-identity #63 Asserts $id names the live domain and site/public/schema/ matches the source

Neither loss was visible in CI. Both are additive validations — deleting them removes coverage without failing anything. #64 went green with them gone, and main is green right now.

This is not theoretical

#64 rewrote the ContextQuery $comment. The served copy under site/public/schema/ was never refreshed, so on main today:

$ diff schema/contextgraph-envelope.schema.json site/public/schema/contextgraph-envelope.schema.json
*** DRIFTED ***

That is exactly the case #63's comment describes — "a stale schema that still resolves is one that silently validates the wrong thing", worse than a 404. The merge introduced the drift and deleted the detector in one move.

The $comment collision

Worth flagging: #63 and #64 fixed the ContextQuery.required bug independently and identically. Both removed kinds/anchors; only the $comment prose differed. This PR takes #63's wording, which is the better text — it names the conformance suite's own sample_query() and records that absence and [] mean the same thing. schema/ is byte-identical to the served copy again.

The CHANGELOG bullet from #64 claiming that schema fix is reworded to claim only what #64 actually contributed uniquely: the regression test and the cross-audit.

Verification

Both restored checks are mutation-tested, not assumed:

# $id check, against main's real current state:
FAIL  the served schema copy is byte-identical to the source

# vector check, with ContextQuery.required reverted to the pre-#63 list:
FAIL  reference-vectors.ndjson line 4
Gate Result
python3 schema/validate-examples.py 39 checks pass (37 on main — the two dropped ones restored)
cargo test --workspace 292 passed, 0 failed
cargo fmt --all --check clean
cargo clippy --workspace --all-targets -- -D warnings clean

Review notes

  • No behavioral change. This restores deleted validation and resyncs a served file. No wire type, schema constraint, or conformance rule changes.
  • Section numbering reconciled: 1–2 examples/, 3 reference vectors, 4 SPEC.md, 5 schema identity.
  • The broader lesson worth capturing: this bug class — a merge that deletes an additive check — is invisible to CI by construction. Green CI on a conflict resolution is not evidence the resolution was clean. Diffing the merge result against both parents is what surfaces it.

#64's merge with main kept its own `schema/validate-examples.py` wholesale,
silently discarding both checks #63 had added to that file:

  * the reference-SERIALIZED vector validation (issue #54) — the half that
    catches schema/serializer disagreement, which curated examples cannot;
  * the `$id` + served-copy check, asserting `$id` names the live domain and
    `site/public/schema/` stays byte-identical to the source.

Neither loss was visible in CI. Both are additive validations, so deleting
them removes coverage without failing anything: #64 was green with them
gone, and main is green now.

The second loss is not theoretical — main is currently serving a stale
schema. #64 rewrote the ContextQuery `$comment`, so the copy under
`site/public/schema/` no longer matches the source. That is the exact
"stale schema that still resolves is worse than a 404" case #63's comment
describes, and the check that would have caught it went out in the same
commit that caused it.

Resolves the drift by taking #63's `$comment` wording over #64's: the two
fixed the same bug independently, and #63's is the better text (it names
the conformance suite's own sample_query() and records that absence and []
mean the same thing). `schema/contextgraph-envelope.schema.json` is
byte-identical to the served copy again.

CHANGELOG: reworded #64's ContextQuery bullet, which claimed a schema fix
that had already landed in #63, to claim only the regression test and the
cross-audit it actually contributed.

Section numbering reconciled: 1-2 examples/, 3 reference vectors, 4 SPEC.md,
5 schema identity.

Both restored checks are mutation-tested rather than assumed: the $id check
fails on main's current drift, and the vector check fails when ContextQuery's
`required` is reverted to the pre-#63 list.

validate-examples.py: 39 checks (37 on main — the two dropped ones back).
cargo test --workspace: 292 passed, 0 failed. fmt and clippy -D warnings clean.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @macanderson, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant