Schema validation: a pattern declined for one schema's compile budget stays declined for every later schema in the session

Ouverte
  • Quelque chose ne va pas ?
#2,934 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
1-2 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
node.js, typescript
Domaine
backend, testing

Piste de recherche

Start with core/mcp/linearPatternValidator.ts and inspect how LinearPattern.toString() and Ajv's pattern scope interact when a compile budget is exhausted. The issue describes a Vitest reproduction under core/mcp/__tests__; run it with schema A followed by schema B on one validator, then confirm B validates as it does with a fresh validator. The fix is done when an exhausted compile for one schema no longer makes a later schema's matching pattern fail.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug v2
Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

All / shared core

Inspector version

2.14.0 (released package; also v2/main @ 3b387d3)

Node version

v22.23.4

Operating system (and browser, for the web client)

Linux (Debian)

Transport

Not applicable / never connected

MCP server under inspection

Not server-specific. Reproduced directly against LinearPatternJsonSchemaValidator (core/mcp/linearPatternValidator.ts), which InspectorClient creates once (this.outputValidator ??= …) and shares for every tool's outputSchema check and every app-rendered elicitation for the life of the client.

Steps to reproduce
  1. One schema (tool A's outputSchema) has 11 distinct patterns near the per-pattern program limit, e.g. ^x0a{0,4990}$ … ^x10a{0,4990}$, plus ^[a-z]+$. It exceeds SCHEMA_COMPILE_BUDGET, so ^[a-z]+$ compiles to { ok: false, reason: "the patterns together exceed the compilation budget" }. That is expected for A.
  2. A second, tiny schema (tool B): { "type": "string", "pattern": "^[a-z]+$" }.
  3. Validate "abc" against B on the same validator.
const v = new LinearPatternJsonSchemaValidator();
v.getValidator(schemaA)({ late: "abc" });     // A: invalid, budget exceeded (expected)
v.getValidator(schemaB)("abc");                // B: ???
Expected behavior

Schema B is compiled against its own fresh budget (as tracked() intends), so "abc" validates: { valid: true }. That's what a fresh validator returns for B alone.

Actual behavior

B is reported invalid with A's reason:

pattern "^[a-z]+$" was not evaluated (the patterns together exceed the compilation budget), so the value could not be verified against the schema

Cause: Ajv's usePattern registers each regex in the engine-wide ValueScope keyed by rx.toString(), which LinearPattern.toString() makes /${source}/${flags}. ValueScope.value() returns the first entry for an existing key, so the failed LinearPattern built while compiling A is the one every later schema on that Ajv engine uses for the same pattern. B's own compile call does run (and charges B's fresh budget), but its result is discarded.

Effect: one server's heavy outputSchema makes structured output of other tools, and app elicitation results, read as "could not be verified" for the rest of the session, with a reason that's false for those schemas. The per-schema budget becomes per-session for any pattern a budget-exhausted schema touched.

Logs, errors, or screenshots

Repro as a vitest file (core/mcp/tests): control (B alone) passes; B-after-A fails with the message above. The linear matcher itself looks right: a differential fuzz against native RegExp (~1.8M pattern×input comparisons, u and non-u) found no divergence.

Already prototyped a fix?

Not a PR. Possible fixes: don't let a budget-declined compilation become the scope entry, e.g. give LinearPattern.toString() a distinct key when !compiled.ok && reason === COMPILE_BUDGET_EXHAUSTED (so a later schema gets its own attempt), or keep a per-engine cache of successful compilations only.

Before you submit
  • I searched existing issues and this is not a duplicate.
  • This is not a security vulnerability report (those go through the private advisory process).
Langage dominant
TypeScript
Étoiles
11.3k
Forks
1.6k
Merge moyen
1 h 28 min
PR mergées (30 j)
138

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/inspector

Toutes les issues de modelcontextprotocol/inspector

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.