[DRAFT] test(e2e): 2026-06 spec backlog — SEP-2260 + SEP-2575/2567 as expected-fail stubs - #2180
Closed
felixweinberger wants to merge 6 commits into
Closed
[DRAFT] test(e2e): 2026-06 spec backlog — SEP-2260 + SEP-2575/2567 as expected-fail stubs#2180felixweinberger wants to merge 6 commits into
felixweinberger wants to merge 6 commits into
Conversation
Unmodified copy of test/e2e from the v1.x e2e suite (requirements manifest, verifies()-style scenario tests, helpers, fixtures). Does not type-check or run against this branch yet; import paths and v2 API adaptation follow in separate commits.
Map the old deep-path imports onto the v2 workspace packages (client, server, core, node, express), apply the v1-to-v2 codemod renames, and add the test/e2e workspace wiring (package.json, tsconfig, vitest and eslint config).
Fix the remaining type and lint errors against the v2 packages, update the manifest for v2 behavior changes (knownFailures added, removed, or reworded), and defer requirements whose v1 surface no longer exists (legacy McpServer overloads, the bundled OAuth authorization server, callTool result schemas). Rewrite the suite CLAUDE.md for the manifest/verifies structure and pnpm commands.
Cover Standard Schema and fromJsonSchema validation, the Hono, Fastify and Express hosting adapters, custom method handlers, the structured handler context, the new error hierarchy, AuthProvider on the HTTP client transport, reconnection scheduling, protocol version and capability options, and failed task results. New requirements are recorded in the manifest with knownFailures where the SDK does not yet meet the documented behavior.
…67 as expected-fail stubs 63 new requirements covering SEP-2260 (server-request association) and the stateless/sessionless cluster (SEP-2575 + SEP-2567), each cited by a deliberately-failing stub in scenarios/spec-2026-06-stubs.test.ts and marked as a knownFailure. No SDK changes; matrix stays at 0 unexpected failures (916 pass + 131 expected-fail). Sub-batch labels (P0, G0, S1-S9) give the proposed implementation order.
|
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
This was referenced May 29, 2026
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds the first two chunks of the 2026-06 (draft) spec release to the e2e suite as 63 new requirements with deliberately-failing stub tests: SEP-2260 (server-request association) and the stateless/sessionless cluster (SEP-2575 + SEP-2567). No SDK code changes. Each requirement is marked as a
knownFailure, so the matrix stays at 0 unexpected failures — the new cells are an executable, ordered todo list for the next spec release.Stacked on the v2 e2e suite port (
fweinberger/e2e-v2); the diff here is onlyrequirements.ts+ one stub scenario file.Motivation and Context
The next spec release is large (stateless/sessionless core, MRTR, tasks-as-extension, plus a dozen smaller SEPs). Implementing it SEP-by-SEP would mean a handful of huge, hard-to-review PRs. This PR proposes the alternative: break each SEP into requirement-level assertions in
requirements.ts, land them up front as failing stubs, and implement them gradually — one small, individually-testable behavior at a time, in a declared order.The development loop per requirement: replace its stub with a real assertion → watch it fail → make the smallest SDK change that turns it green without breaking the existing 916 passing cells → delete the knownFailure → small PR named for the requirement(s). The suite is the ledger: "what's left" is the expected-fail count.
How we avoid one giant stateless PR — the NotImplemented gate. The first implementation sub-batch (G0) makes only this true: a client and server can agree on the 2026 version, and once they have, every operation on that negotiated path fails fast with a NotImplemented error. 2025 clients on the same server are completely unaffected (dual-stack: both doors stay open). Every subsequent sub-batch then replaces one NotImplemented throw with real behavior and turns its requirements green — so each piece of 2026 work has a precise, pre-existing integration point, every PR stays small, and at every moment the SDK is honest about what it supports.
Proposed implementation order (each row = one or a few small PRs):
server/discover+ version errorssupported[]; client retry/downgrade_metaenvelope stampingsubscriptions/listenAfter S8 the stateless cluster is complete and the gate is gone. MRTR (SEP-2322), extensions (SEP-2133), and tasks (SEP-2663) follow as their own requirement sets using the same pattern — MRTR staged progressively (tool calls without elicitation → MRTR-native elicitation → await-form emulated over MRTR).
Notes on mechanics:
[SEP-XXXX]and the acceptance-criteria row reference (R-…), so each entry traces back to the spec clause it asserts.addedInSpecVersionversion-gating is added) as each sub-batch is implemented.How Has This Been Tested?
Full e2e suite on this branch: 32 files, 916 passed + 131 expected-fail (1047 cells), 0 unexpected failures, ~20s. The 63 new cells are all expected-fail stubs (68 → 131). Typecheck, eslint, and prettier clean.
Breaking Changes
None — test-only. No SDK code or published package is touched.
Types of changes
Checklist
Additional context
[DRAFT]on purpose: this PR is the proposal for how the release gets implemented as much as it is the first slice of it. Feedback wanted on (a) the requirement granularity, (b) the sub-batch order, and (c) the NotImplemented-gate approach to keeping the stateless cluster incremental.