fix: inject progressToken when resetTimeoutOnProgress is set (not only onprogress)

[techtoboggan]

Problem

resetTimeoutOnProgress: true in RequestOptions has no effect unless onprogress is also provided, because _meta.progressToken is only injected when onprogress exists:

// packages/core/src/shared/protocol.ts (before this PR)
if (options?.onprogress) {          // ← only path that injects progressToken
    this._progressHandlers.set(messageId, options.onprogress);
    jsonrpcRequest.params = { ..., _meta: { progressToken: messageId } };
}

this._setupTimeout(
  messageId, timeout, ...,
  options?.resetTimeoutOnProgress ?? false,  // ← flag is stored but never fires
);

The _onprogress handler (line ~668) matches incoming notifications/progress by params.progressToken → messageId. Without a token in the request, the server's notifications cannot be matched — _resetTimeout is never called — and the request times out at DEFAULT_REQUEST_TIMEOUT_MSEC regardless of how often the server sends progress.

Reproduction: Any tool call where the server sends periodic progress notifications and the client passes { resetTimeoutOnProgress: true } without onprogress times out at 60s. Tracked in issue #245.

Fix

Expand the injection condition from if (options?.onprogress) to if (options?.onprogress || options?.resetTimeoutOnProgress). The progressToken is now injected in both cases, so the server's notifications/progress can be matched and _resetTimeout fires correctly.

The onprogress handler registration is unchanged — a no-op token injection (when only resetTimeoutOnProgress is set) does not register a progress handler, so no memory is wasted on empty callbacks.

// after this PR
if (options?.onprogress || options?.resetTimeoutOnProgress) {
    if (options.onprogress) {
        this._progressHandlers.set(messageId, options.onprogress);
    }
    jsonrpcRequest.params = { ..., _meta: { progressToken: messageId } };
}

Why this matters

MCP servers providing long-running HITL tools (human-in-the-loop, waiting for user input) rely on progress notifications to keep calls alive. Clients that set resetTimeoutOnProgress: true expect this to work. Prior to this fix, the flag was silently ignored unless the client also provided a callback, making it effectively unusable without reading the source.

Closes #245

[changeset-bot]

⚠️ No Changeset found

Latest commit: 743a887

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/fastify

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 743a887

[travisbreaks]

The fix is correct. Without this, resetTimeoutOnProgress alone (without onprogress) never injects the progressToken into the request _meta, so the server has no token to send progress notifications back to, and timeout reset never triggers.

One thing: the options.onprogress check is now evaluated twice (outer || and inner if). Not a real concern at this scale, but worth noting that options is already guaranteed non-null inside the block since the outer condition checked it. Clean fix overall.