Skip to content

fix(client): thread onresumptiontoken and onRequestStreamEnd through the send() resume path#2519

Open
lntutor wants to merge 1 commit into
modelcontextprotocol:mainfrom
lntutor:fix/send-resume-callbacks
Open

fix(client): thread onresumptiontoken and onRequestStreamEnd through the send() resume path#2519
lntutor wants to merge 1 commit into
modelcontextprotocol:mainfrom
lntutor:fix/send-resume-callbacks

Conversation

@lntutor

@lntutor lntutor commented Jul 19, 2026

Copy link
Copy Markdown

What's broken

When send() is called with a resumptionToken (the documented flow for resuming a long-running request after a disconnect), the resume branch reopens the SSE stream with the correct Last-Event-ID — but forwards neither onresumptiontoken nor onRequestStreamEnd to _startOrAuthSse():

if (resumptionToken) {
    this._startOrAuthSse({
        resumptionToken,
        replayMessageId: isJSONRPCRequest(message) ? message.id : undefined,
        requestSignal: options?.requestSignal   // threaded — but the two callbacks in the same options object are not
    }).catch(error => this.onerror?.(error));
    return;
}

Both callbacks arrive in the same options object (Protocol forwards { resumptionToken, onresumptiontoken, requestSignal } on every transport.send), and the original POST path threads both (_send, further down), as does resumeStream() for the identical stream. The comment above the resume branch shows requestSignal was threaded deliberately; the two callbacks sitting next to it were overlooked.

Observable failure

For the rest of a resumed request's life — including all of its internal reconnects, which rebuild options from StartSSEOptions — the caller's onresumptiontoken never fires again. The host's persisted token goes permanently stale, so a later resume replays already-delivered events (duplicate responses/side effects) or falls outside the server event store's retention window entirely. onRequestStreamEnd is dropped on the same line, so a resumed per-request stream that dies non-resumably never notifies the caller.

Related but distinct from #2499 / #2509: that fix seeds _handleSseStream's internal lastEventId tracker from the token; this one is about the caller-facing callbacks never being attached on the send() resume path at all. Even with #2509 merged, the callback still never fires here.

Fix

Thread onresumptiontoken and onRequestStreamEnd through the resume branch's _startOrAuthSse() call, matching the POST path and resumeStream().

Tests

New test in packages/client/test/client/streamableHttp.test.ts: resumes via send(..., { resumptionToken, onresumptiontoken, onRequestStreamEnd }) against a mocked GET SSE stream that delivers one id-bearing event and ends non-resumably (maxRetries: 0). Before the fix the GET goes out with the right Last-Event-ID but neither callback ever fires; after the fix both do. Full @modelcontextprotocol/client suite passes (749 tests), typecheck and lint clean. Changeset included (patch).

🤖 Generated with Claude Code

https://claude.ai/code/session_01N6RtoHuxrDqTUo9Mw9h4Cv

…the send() resume path

The resumptionToken branch of StreamableHTTPClientTransport._send()
reopened the SSE stream with the right Last-Event-ID but passed neither
onresumptiontoken nor onRequestStreamEnd to _startOrAuthSse(), while the
original POST path and resumeStream() both thread them. A caller
resuming a long-running request therefore never saw newer resumption
tokens (its persisted token went stale, causing replayed or lost events
on the next resume) and never learned when the stream ended
non-resumably.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N6RtoHuxrDqTUo9Mw9h4Cv
@lntutor
lntutor requested a review from a team as a code owner July 19, 2026 07:54
@changeset-bot

changeset-bot Bot commented Jul 19, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 713c448

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages
Name Type
@modelcontextprotocol/client Patch
@modelcontextprotocol/core Patch
@modelcontextprotocol/server Patch
@modelcontextprotocol/server-legacy Patch
@modelcontextprotocol/codemod Patch
@modelcontextprotocol/core-internal Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@pkg-pr-new

pkg-pr-new Bot commented Jul 19, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2519

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2519

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2519

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2519

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2519

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2519

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2519

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2519

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2519

commit: 713c448

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant