Implement SEP-2260: Require Server requests to be associated with a Client request #2186

Activity

1. felixweinberger

   added this to 2026-07-28 Spec Implementationon May 29, 2026
2. github-project-automation

   moved this to Todo in 2026-07-28 Spec Implementationon May 29, 2026
3. mattzcarey commented on May 29, 2026

   

   mattzcarey

   on May 29, 2026

   Member

   More actions

   Status — SEP-2260 (Server requests associated with Client requests)

   Track: A (core, sequential spine) — starts now (current spec, doesn't require 2026-06 mode)
   Spec: seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md · merged & marked Final in spec#2730

   What's done

   • Nothing in main yet.
   • Closed exploration: feat(server): handleHttp() per-request entry, SessionCompat, dual-conformance #2058 (handleHttp() per-request entry, SessionCompat, dual-conformance) — Felix's r3-handlehttp branch laid the per-request HTTP entry-point groundwork the bugfix will land into.

   Outstanding (acceptance criteria from the spec page)

   • R-2260-1 (wire): s→c requests (roots/list, sampling/createMessage, elicitation/create) MUST only be sent on the POST-response SSE stream of an originating client request.
   • R-2260-3 (sdk): no API for unsolicited s→c.
   • R-2260-4 (wire): SSE keepalive SHOULD be used during nested waits.
   • R-2260-5 (wire): client receiving an orphan s→c request SHOULD respond -32602.
   • R-2260-6 (wire): GET-initiated standalone SSE streams MUST NOT carry s→c requests (notifications/pings only).
   • R-2260-7 / 8 (guidance): timeouts accommodate human-in-the-loop delays; ping exempt.

   Fixes long-standing bugs #963 and #1167.

   Test backlog

   • [DRAFT] test(e2e): 2026-06 spec backlog — SEP-2260 + SEP-2575/2567 as expected-fail stubs #2180 (DRAFT) adds the 2260 + 2575/2567 acceptance criteria to the v2 e2e suite as known-failure stubs — adopt as the conformance ratchet for this issue.

   Open spec PRs to watch

   • None active (SEP marked Final 2026-05-15).

   Suggested first PR

   Standalone bugfix (~90 LOC per the spec-page sequencing plan): ensure ctx.elicit / ctx.sample only emit on the originating request's response stream, never on a separate channel. Lands on current-spec code, doesn't need 2026-06 mode.
4. felixweinberger

   self-assigned this

   on May 29, 2026
5. felixweinberger

   moved this from Todo to In Progress in 2026-07-28 Spec Implementationon May 29, 2026
6. felixweinberger commented on Jun 1, 2026

   

   felixweinberger

   on Jun 1, 2026

   ContributorAuthor

   More actions

   Scope clarification from implementation analysis: SEP-2260's MUST-strength rules never landed in the published 2025-11-25 spec pages (they remain SHOULD-strength there: server→client messages "SHOULD relate to the originating client request"), and in the current draft spec they are enforced structurally by MRTR (SEP-2322) rather than as standalone rules.

   So this issue's deliverables split as follows:

   1. 2025-lineage improvements — delivered by fix(server): associate ctx-scoped elicitation/sampling with the originating request (SEP-2260) #2228: ctx-scoped elicitation/sampling requests now carry relatedRequestId and ride the originating request's response stream, plus an opt-in SSE keepalive for long nested waits.
   2. The remaining rules (client rejects unsolicited server→client requests; no API for unsolicited pushes) assert draft-era semantics and are delivered by the MRTR implementation (Implement SEP-2322: Multi Round-Trip Requests #2187), where they hold by construction.

   No separate "SEP-2260 implementation" beyond these two pieces should be expected.
7. norika1207-lab commented on Jun 2, 2026

   

   norika1207-lab

   on Jun 2, 2026 · Hidden as spam

   show commentMore actions
8. felixweinberger

   moved this from In Progress to Done in 2026-07-28 Spec Implementationon Jun 24, 2026
9. felixweinberger

   closed this as completedby moving to Done in 2026-07-28 Spec Implementationon Jun 24, 2026