test(conformance): arm the fixtures for the input-required scenario family

test/conformance/expected-failures.2026-07-28.yaml

@@ -48,9 +48,6 @@ client:
     - auth/scope-retry-limit
 
     # --- Same gaps as the 2025 baseline (fail identically when forced to 2026-07-28) ---
-    # SEP-2322 (multi-round-trip requests): client does not echo requestState /
-    # handle IncompleteResult yet.
-    - sep-2322-client-request-state
     # SEP-2243 (HTTP standardization): no fixture handler / client header support yet.
     - http-custom-headers
     - http-invalid-tool-headers
@@ -86,21 +83,3 @@ server:
     # (Mcp-Method, Mcp-Name) and the Mcp-Name cross-check are not implemented,
     # so those reject cells are still accepted with 200.
     - http-header-validation
-    # SEP-2322 (multi-round-trip requests / IncompleteResult): not implemented
-    # in the SDK, so the fixture does not register the scenarios' diagnostic
-    # test_input_required_result_* tools.
-    - input-required-result-basic-elicitation
-    - input-required-result-basic-sampling
-    - input-required-result-basic-list-roots
-    - input-required-result-request-state
-    - input-required-result-multiple-input-requests
-    - input-required-result-multi-round
-    - input-required-result-non-tool-request
-    - input-required-result-result-type
-    - input-required-result-tampered-state
-    - input-required-result-capability-check
-    # SEP-2322 SHOULD-level behaviours (re-request missing inputResponses,
-    # ignore unrecognized inputResponses keys): WARNING-only, but the
-    # expected-failures evaluator counts WARNINGs as failures.
-    - input-required-result-missing-input-response
-    - input-required-result-ignore-extra-params

test/conformance/expected-failures.yaml

@@ -18,9 +18,6 @@
 
 client:
     # --- Draft-spec scenarios (in `--suite draft`, also part of `--suite all`) ---
-    # SEP-2322 (multi-round-trip requests): client does not echo requestState /
-    # handle IncompleteResult yet.
-    - sep-2322-client-request-state
     # SEP-2243 (HTTP standardization): no fixture handler / client header support yet.
     - http-custom-headers
     - http-invalid-tool-headers
@@ -52,29 +49,12 @@ client:
 
 server:
     # --- Draft-spec scenarios (in `--suite draft`; the default `active` suite is green) ---
-    # SEP-2322 (multi-round-trip requests / IncompleteResult): not implemented
-    # in the SDK, so the fixture does not register the scenarios' diagnostic
-    # test_input_required_result_* tools.
-    - input-required-result-basic-elicitation
-    - input-required-result-basic-sampling
-    - input-required-result-basic-list-roots
-    - input-required-result-request-state
-    - input-required-result-multiple-input-requests
-    - input-required-result-multi-round
-    - input-required-result-non-tool-request
-    - input-required-result-result-type
-    - input-required-result-tampered-state
-    - input-required-result-capability-check
     # SEP-2243 (HTTP header standardization): the reject cells the SDK does
     # answer now use -32001 (HeaderMismatch), but missing-header enforcement
     # (Mcp-Method, Mcp-Name) and the Mcp-Name cross-check are not implemented,
     # so those reject cells are still accepted with 200.
     - http-header-validation
-    # WARNING-only entries: these scenarios emit no FAILURE checks, only SHOULD-level
-    # WARNINGs, but the expected-failures evaluator counts WARNINGs as failures.
+    # WARNING-only entry: the scenario emits no FAILURE checks, only a SHOULD-level
+    # WARNING, but the expected-failures evaluator counts WARNINGs as failures.
     # SEP-2164: server returns -32002 without the requested URI in error.data.
     - sep-2164-resource-not-found
-    # SEP-2322 SHOULD-level behaviours (re-request missing inputResponses, ignore
-    # unrecognized inputResponses keys).
-    - input-required-result-missing-input-response
-    - input-required-result-ignore-extra-params

test/conformance/src/everythingClient.ts

@@ -235,6 +235,107 @@ registerScenario('initialize', runBasicClient);
 registerScenario('tools_call', runToolsCallClient);
 registerScenario('request-metadata', runRequestMetadataClient);
 
+// ============================================================================
+// Multi-round-trip client scenario (SEP-2322, protocol revision 2026-07-28)
+// ============================================================================
+
+/**
+ * The multi-round-trip client scenario's mock server only implements
+ * `tools/list`, `tools/call` and `notifications/initialized`; it answers both
+ * `server/discover` and `initialize` with -32601, so neither connect-time
+ * negotiation path can establish the 2026-07-28 era against it. The scenario
+ * is pinned to 2026-07-28 (the runner resolves it there even on the
+ * default-version leg), so the fixture answers the connect-time
+ * `server/discover` probe locally through the transport's custom fetch and
+ * lets every other request reach the real mock. Everything the scenario
+ * measures — auto-fulfilment of the embedded elicitation, the byte-exact
+ * requestState echo, fresh JSON-RPC ids on retries, isolation of unrelated
+ * calls, and not retrying complete results — is the SDK driver's behavior
+ * against the real mock.
+ */
+function withLocalDiscoverResponse(serverInfo: { name: string; version: string }): typeof fetch {
+    return async (input, init) => {
+        if (typeof init?.body === 'string') {
+            try {
+                const message = JSON.parse(init.body) as { method?: string; id?: unknown };
+                if (message.method === 'server/discover') {
+                    return Response.json(
+                        {
+                            jsonrpc: '2.0',
+                            id: message.id,
+                            result: {
+                                supportedVersions: ['2026-07-28'],
+                                capabilities: { tools: { listChanged: true } },
+                                serverInfo
+                            }
+                        },
+                        { status: 200, headers: { 'Content-Type': 'application/json' } }
+                    );
+                }
+            } catch {
+                // Not a JSON-RPC body — fall through to the real fetch.
+            }
+        }
+        return fetch(input, init);
+    };
+}
+
+async function runMrtrClient(serverUrl: string): Promise<void> {
+    const clientInfo = { name: 'test-client', version: '1.0.0' };
+    const capabilities = { elicitation: {} };
+    const client = new Client(clientInfo, {
+        capabilities,
+        versionNegotiation: { mode: 'auto' }
+    });
+
+    // The auto-fulfilment driver dispatches the embedded elicitation requests
+    // to this handler, exactly like a server-initiated elicitation.
+    client.setRequestHandler('elicitation/create', async request => {
+        logger.debug('Fulfilling embedded elicitation request:', JSON.stringify(request.params));
+        return { action: 'accept' as const, content: { confirmed: true } };
+    });
+
+    const transport = new StreamableHTTPClientTransport(new URL(serverUrl), {
+        fetch: withLocalDiscoverResponse(clientInfo)
+    });
+
+    await client.connect(transport);
+    logger.debug('Negotiated protocol version:', client.getNegotiatedProtocolVersion());
+
+    const envelope = modernEnvelope(clientInfo, capabilities, client.getNegotiatedProtocolVersion());
+
+    // requestState echo flow: the driver must echo the opaque state byte-exact
+    // and retry on a fresh JSON-RPC id.
+    const echoResult = await client.callTool({ name: 'test_mrtr_echo_state', arguments: {}, _meta: envelope });
+    logger.debug('test_mrtr_echo_state result:', JSON.stringify(echoResult));
+
+    // No-state flow: the InputRequiredResult carries no requestState, so the
+    // retry must not include one.
+    const noStateResult = await client.callTool({ name: 'test_mrtr_no_state', arguments: {}, _meta: envelope });
+    logger.debug('test_mrtr_no_state result:', JSON.stringify(noStateResult));
+
+    // Unrelated call: must not carry inputResponses or requestState from the
+    // multi-round-trip flows above.
+    const unrelatedResult = await client.callTool({ name: 'test_mrtr_unrelated', arguments: {}, _meta: envelope });
+    logger.debug('test_mrtr_unrelated result:', JSON.stringify(unrelatedResult));
+
+    // Result without resultType: the check passes as long as the client does
+    // not retry with inputResponses. The SDK treats a missing resultType from
+    // a 2026-negotiated server as a protocol violation and rejects locally
+    // without retrying, so this call is expected to throw.
+    try {
+        const noResultTypeResult = await client.callTool({ name: 'test_mrtr_no_result_type', arguments: {}, _meta: envelope });
+        logger.debug('test_mrtr_no_result_type result:', JSON.stringify(noResultTypeResult));
+    } catch (error) {
+        logger.debug('test_mrtr_no_result_type rejected locally (no retry):', error instanceof Error ? error.message : String(error));
+    }
+
+    await client.close();
+    logger.debug('Connection closed successfully');
+}
+
+registerScenario('sep-2322-client-request-state', runMrtrClient);
+
 // ============================================================================
 // Auth scenarios - well-behaved client
 // ============================================================================