Fix [mcp client times out after 60 seconds (ignoring timeout option) #245]

[andrea-tomassi]

This PR fixes the timeout issue where MCP clients would timeout after 60 seconds even when receiving progress notifications from servers performing long-running operations.

Problem
The TypeScript/JavaScript SDK was timing out after 60 seconds regardless of progress updates from the server, while the Python SDK correctly handled progress notifications by resetting the timeout. This inconsistency caused issues for users with long-running MCP tools that send periodic progress updates.

Error encountered:

McpError: MCP error -32001: Request timed out
at Timeout.timeoutHandler (file:///.../@modelcontextprotocol/sdk/dist/esm/shared/protocol.js:282:49)
...
code: -32001,
data: { timeout: 60000 }
Root Cause
The resetTimeoutOnProgress option in RequestOptions defaulted to false, meaning that progress notifications would not reset the request timeout. This required users to explicitly opt-in to the intuitive behavior of keeping connections alive when progress is being reported.

Solution
Changed the default value of resetTimeoutOnProgress from false to true, making the TypeScript/JavaScript SDK behave consistently with the Python SDK. This ensures that:

Progress notifications automatically reset the timeout by default
Long-running operations with progress updates won't timeout prematurely
Backward compatibility is maintained (users can still set resetTimeoutOnProgress: false explicitly)
Changes
Protocol behavior: resetTimeoutOnProgress now defaults to true instead of false
Documentation: Updated JSDoc comments to reflect the new default
Tests: Added comprehensive test coverage for the new default behavior and updated existing tests to prevent interference
Verification
The fix has been verified with:

All existing tests pass (670 total tests)
New test specifically validates default timeout reset behavior
Manual testing with demonstration script confirms progress notifications reset timeout
Build and linting pass successfully
Example of the fix in action:

// Before: Would timeout after 60s despite progress
const result = await client.request(longRunningRequest, schema, {
onprogress: (progress) => console.log(progress)
});

// After: Automatically resets timeout on each progress notification
const result = await client.request(longRunningRequest, schema, {
onprogress: (progress) => console.log(progress) // timeout resets on each call
});
Fixes mcp client times out after 60 seconds (ignoring timeout option) #245

[jonathanhaviv]

hey quick question, I was wondering why we're choosing to have this setting default to true vs having the client actually respect the timeout setting? I think this is probably a good change, but feels like the bigger issue would still be present.

[ochafik]

Hi @andrea-tomassi , thanks for sending this!

I don't think we should change the default. If the user just provides a timeout (because they have a time budget in their app), they should absolutely expect things to succeed or fail within that budget. The fact that the server sends progress forever shouldn't change that by default (but then, if the user decides so, they can set resetTimeoutOnProgress: true).

Python SDK correctly handled progress notifications by resetting the timeout.

I'm not sure that's the case (cf. likely relevant code), please let me know if you find a better reference for this :-)

Hope it makes sense, please let me know if not ✌️

[andrea-tomassi]

Totally agree with you on the fact that the user's choice (if provided) should be the one that is used. In that case the default should not be considered any more, in fact the user's explicit value should br an override for the default value.

I'm not sure if I'm missing something here, or if this is just a bug.

[andrea-tomassi]

Just to be clear, the one I proposed is barely a work around, not an actual fix. In my mind the user's value should be uses. However, I lack of the complete picture here.