Define handling for protocol-incompatible result properties set by applications
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
- 技術スタック
- csharp
調査の方向性
共有のポストハンドラー境界から開始し、McpServerImpl.IsJuly2026OrLaterProtocolRequest が RequestContext.JsonRpcRequest.Context.ProtocolVersion と McpServer.NegotiatedProtocolVersion をどのように解決するかを読みます。選択する前に提案されたポリシーを比較し、その後、通常の結果、キャッシュ可能な結果、即時の代替結果の出力を追跡します。完了条件は、選択した動作が定義され、正確な wire 形式のテストが、一覧にあるプロトコルコンテキスト、ハンドラー、フィルター、再利用された結果インスタンスをカバーしていることです。
索引モデルが issue の本文から書いたものです。
説明
Summary
PR #1753 fixes #1721 by stopping the SDK from automatically adding the 2026-07-28-only resultType, ttlMs, and cacheScope properties to legacy results. Applications can still set those properties explicitly from handlers or filters, which can produce a wire shape that is invalid for the negotiated protocol version.
We should define and consistently enforce the server behavior for protocol-version-specific result properties supplied by application code.
Protocol detection
The effective protocol version is already available at the shared post-handler boundary:
- Use
RequestContext.JsonRpcRequest.Context.ProtocolVersionfor per-request metadata protocols. - Fall back to
McpServer.NegotiatedProtocolVersionfor stateful sessions. McpServerImpl.IsJuly2026OrLaterProtocolRequestalready implements this resolution.
Possible policies
- Fail the request before serialization with an InternalError and a useful server-side diagnostic. This gives application developers the strongest signal, but turns an otherwise valid client request into an error. Ordinary application exceptions currently produce a generic
"An error occurred."response, so we would also need to decide whether the client receives a specific message. - Strip the unsupported properties and log a warning. This preserves a valid legacy wire shape while making the application misuse visible to server operators.
- Strip the unsupported properties silently. This maximizes compatibility but can hide application bugs.
Scope
The selected policy should:
- Be applied once at a typed response-emission boundary after handlers and filters.
- Cover
Result.ResultTypeand bothICacheableResultproperties. - Cover normal, cacheable, and immediate alternate results.
- Avoid mutating shared response instances in a way that can affect later requests using another protocol version.
- Preserve explicit values and add required defaults for 2026-07-28 and later responses.
- Be extensible to future protocol-version-specific result properties.
Tests
Add exact serialized wire-shape coverage for:
- Legacy handlers and filters that explicitly set each unsupported property.
- 2026-07-28 handlers and filters with explicit values.
- Normal, cacheable, and immediate alternate results.
- Session-negotiated and per-request HTTP protocol contexts.
- Reused or shared result instances across requests with different protocol versions.
- 主要言語
- C#
- スター
- 4.5k
- フォーク
- 814
- 平均マージ
- 9日 19時間
- マージ済み PR(30日)
- 4
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/csharp-sdk のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
modelcontextprotocol/csharp-sdk#1867 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
modelcontextprotocol/csharp-sdk#1840 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
modelcontextprotocol/csharp-sdk#1836 ·
-
enhancement needs confirmation
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
modelcontextprotocol/csharp-sdk#678 · コメント 1 件 ·
-
enhancement needs confirmation P3 ready for work
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/csharp-sdk#515 · コメント 6 件 · リアクション 3 件 ·
modelcontextprotocol/csharp-sdk の issue をすべて見る
似ている issue
-
type/automation type/tech-debt
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
t/bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
ci-failure-cause test-failure
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
area:auth FE mvp P3
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
klasolsson81/jobbliggaren#1788 ·