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

オープン
  • 何か問題がありますか？
#2,934 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
1〜2日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
node.js, typescript
領域
backend, testing

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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).
主要言語
TypeScript
スター
11.3k
フォーク
1.6k
平均マージ
1時間 28分
マージ済み PR（30日）
138

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/inspector のほかの issue

modelcontextprotocol/inspector の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。