Skip to content

chore: update spec.types.ts from upstream #2027

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
github-actions wants to merge 1 commit into
base: main
Choose a base branch
from
+1 −1
Open

chore: update spec.types.ts from upstream #2027

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion packages/core-internal/src/types/spec.types.2026-07-28.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
*
* Source: https://github.com/modelcontextprotocol/modelcontextprotocol
* Pulled from: https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/main/schema/draft/schema.ts
* Last updated from commit: f68d864a813754e188c6df52dcc5772a12f96c63
* Last updated from commit: 93671a3f2bac3bc11b0eb6327c2d029e272b2871

@claude claude Bot Jul 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 The two prior comments covering this exact situation (#3485357818's rule-4 remediation and #3487174588's content-noop verification) were written against the previous re-pull (2ffc3fa2), but this PR now records upstream commit 93671a3f in the anchor header — so following the earlier comment's command verbatim (pnpm fetch:schema-twins 2ffc3fa2...) would stamp the manifests with a third commit and recreate the rule-4 anchor↔manifest provenance skew. Any twin/fixtures manifest refresh landed with this PR must pin 93671a3f (or whatever the anchor records at merge time) instead; re-verified against the new head, the upstream delta between f68d864a and 93671a3f is formatting-only (schema.json hash unchanged, no examples touched), so the close-as-no-op / land-with-manifest-refresh options from the prior comments remain valid.

Extended reasoning...

What this corrects

This re-pull moves the anchor's provenance header (packages/core-internal/src/types/spec.types.2026-07-28.ts:6) from f68d864a813754e188c6df52dcc5772a12f96c63 to 93671a3f2bac3bc11b0eb6327c2d029e272b2871. The two most recent review comments covering exactly this situation were written against the previous re-pull (2ffc3fa2d00e637ae7c3d1438aaa0561ddfda184) and are now stale in ways that matter for whoever acts on them:

  1. #3485357818 (rule-4 anchor↔manifest skew) instructs: "run pnpm fetch:schema-twins 2ffc3fa2d00e637ae7c3d1438aaa0561ddfda184 … so both manifests record the same commit as the anchor." Following that command verbatim against the current head would stamp packages/core-internal/test/corpus/schema-twins/manifest.json (and, via fetch:spec-examples, test/corpus/fixtures/2026-07-28/manifest.json) with 2ffc3fa2 while the anchor header says 93671a3f — recreating the very anchor↔derived-artifact provenance disagreement that lifecycle rule 4 (packages/core-internal/src/types/README.md, marked OPERATIVE) forbids, just at a different pair of commits.
  2. #3487174588 (verified content-noop) based its close-as-no-op recommendation on upstream schema/draft/schema.ts and schema.json being byte-identical between f68d864a and 2ffc3fa2. That specific verification does not automatically carry over to the new head.

Re-verification against the new head (93671a3f)

  • Between f68d864a and 93671a3f, upstream schema/draft/schema.ts does change (96,322 → 96,256 bytes, 63 diff lines) — but every changed hunk is pure union-type re-wrapping (multi-line | A | B | C; collapsed to a single line) with zero semantic or JSDoc change. Prettier in scripts/fetch-spec-types.ts normalizes this away, which is why the regenerated anchor body is byte-identical and this PR's diff is still header-only.
  • schema/draft/schema.json at 93671a3f is unchanged: 178,613 bytes, sha256 14398c3dd2c66b9c3f6661fc7a7eaa24174952ed1598d0b7f011b686ba5c4c83, exactly matching the hash pinned for the 2026-07-28 twin in schema-twins/manifest.json — so the vendored twin oracle remains content-current.
  • The upstream compare f68d864a…93671a3f (16 commits, 27 files) touches no file under schema/draft/examples, so the fixtures corpus at test/corpus/fixtures/2026-07-28/ is also content-current.

Concrete step-by-step consequence of following the stale command

  1. A maintainer decides to satisfy rule 4 by landing a manifest refresh with this PR and copies the command from #3485357818: pnpm fetch:schema-twins 2ffc3fa2d00e637ae7c3d1438aaa0561ddfda184.
  2. Both manifests now record source.commit = 2ffc3fa2.
  3. The anchor header on this PR's head says 93671a3f.
  4. main after merge is again in the state rule 4 forbids — anchor and derived twins disagreeing on their upstream commit — only now across three different SHAs (f68d864a in history, 2ffc3fa2 in the manifests, 93671a3f in the anchor). Nothing in CI catches it: schemaTwinConformance.test.ts hashes only twin bytes and never cross-checks source.commit against the anchor header.

What remains valid, and the recurring-churn point

The prior comments' bottom-line options remain valid for the current head — the content is verified unchanged, so the PR can either be closed as a no-op or landed together with a 2026-07-28-only twin/fixtures manifest refresh, pinned to 93671a3f (or whatever commit the anchor records at merge time), not the SHA quoted in the earlier comment. This is now the second consecutive header-only refresh PR (f68d864a → 2ffc3fa2 → 93671a3f), which reinforces the already-suggested workflow fixes: make the drift check ignore the provenance line (git diff -I 'Last updated from commit:') or have fetch-spec-types.ts skip the write when the regenerated body is unchanged, so content-neutral upstream touches of schema/draft/schema.ts stop generating these PRs.

Why nit

The PR is already held and both prior findings are already on record; nothing newly breaks. This comment corrects the SHA in the porting/remediation instructions and re-establishes the content-noop verification against the new revision so the maintainer acting on the earlier comments doesn't recreate the provenance skew — the same stale-checklist-correction tier already established on this PR.

*
* DO NOT EDIT THIS FILE MANUALLY. Changes will be overwritten by automated updates.
* To update this file, run: pnpm run fetch:spec-types 2026-07-28
Expand Down