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

Abierto
  • ¿Algo no está bien?
#2,934 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
backend, testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).
Lenguaje dominante
TypeScript
Estrellas
11.3k
Forks
1.6k
Merge medio
1 h 28 min
PR fusionados (30 d)
138

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/inspector

Todos los issues de modelcontextprotocol/inspector

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.