Repository navigation
[v2] Last-Event-ID resumability on modern createMcpHandler path #3037
Description
Question
Is Last-Event-ID based stream resumability intentionally out of scope on the modern createMcpHandler path, or supported through a non-obvious seam?
Context
The pre-2.0 NodeStreamableHTTPServerTransport accepted an eventStore (e.g. the SDK's own InMemoryEventStore) that persisted JSON-RPC events keyed by Last-Event-ID, so a client that dropped mid-stream could resume cleanly on reconnect.
On the modern path, CreateMcpHandlerOptions exposes no event-store option and I cannot find a comparable seam in McpHttpHandler or ServerEventBus. A downstream project migrating from the pre-2.0 transport to createMcpHandler loses resumability as a side effect of the swap.
Specific questions
- Is resumability intentionally dropped from the modern (2026-07-28) handler-dispatch path?
- If it is retained, where does an integrator pass the event store? Is it hidden on
WebStandardStreamableHTTPServerTransport/PerRequestHTTPServerTransportconfiguration? - If it is dropped, is there a recommended approximation for long-lived
subscriptions/listenstreams, where a mid-stream drop is more likely than for request/response calls?
Downstream context
accordproject/apap#260migrated tocreateMcpHandler + InMemoryServerEventBusand lost theeventStoreseam as a side effect. The project is tracking this issue to decide between documenting the regression or restoring resumability if a seam exists.
Activity
IlyaKhalafi commentedon Oct 18, 2026
Yes, this is a protocol change. The 2026-07-28 HTTP specification explicitly excludes SSE resumption through
Last-Event-IDand says to ignore that header.There is no modern event-store option to wire up. At this SDK revision,
bussupplies change notifications.ServerEventBusexposes publish and subscribe, without a replay cursor or history contract. The older transport’seventStoredoes not add resumption to modernsubscriptions/listen.For reconnect recovery, I’d open a new listen request, wait for its acknowledgement and accepted filters, and refresh the relevant lists or resources. Queue notifications received during refresh and re-read affected state afterward. This is application-level catch-up, not guaranteed replay of every missed event. If every event matters, expose a separate versioned event log or cursor API.
For clients still speaking the older protocol, the SDK documents routing with
isLegacyRequestto your existing sessionful handler, alongside a modern handler configured withlegacy: 'reject'. That preserves the older handler’s event-store path for older traffic, without extending the modern protocol. This assessment is from the specification and SDK source, not a test of APAP.