[BUG] Support for long running tasks through progress report not working

[m-ibm]

Problem (one or two sentences)

I have MCP tools that are long running tasks (minutes to hours).
These time out in RooCode even though I make sure to send every few seconds (usually 10) both a "still working .." message and set a progress value (without total, therefore this is just an ever increasing number) using the MCP context (ctx.report_progress() and ctx.log())

Note that, a less preferable, solution is to allow arbitrary timeout values.

Context (who is affected and when)

Everyone running long running tasks

Reproduction steps

Start a long running task which runs over the timeout set for the MCP server

Expected result

I expect progress report message to restart the timeout clock since tool is clearly not stuck

Actual result

Timeout for the task although tool keeps working

Variations tried (optional)

As mentioned above I tried:

1. Sending ctx.log() messages
2. Sending ctx.report_progress() messages

App Version

v3.37.0

API Provider (optional)

Not Applicable / Other

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and found the solution. The MCP SDK (v1.12.0) already supports a resetTimeoutOnProgress option in request options, which resets the timeout whenever a progress notification is received.

Proposed Implementation Plan

File to modify: src/services/mcp/McpHub.ts

Change: In the callTool method (around line 1723), add resetTimeoutOnProgress: true to the request options:

return await connection.client.request(
    {
        method: "tools/call",
        params: {
            name: toolName,
            arguments: toolArguments,
        },
    },
    CallToolResultSchema,
    {
        timeout,
        resetTimeoutOnProgress: true, // <-- Add this line
    },
)

How this solves the issue:

• When resetTimeoutOnProgress: true is set, each ctx.report_progress() notification from the MCP server will reset the timeout clock
• This means long-running tasks that send progress updates every 10 seconds will never timeout, as long as they keep sending progress
• The base timeout still applies for the initial wait and between progress updates (default 60 seconds per server config)

Additional considerations:

• The SDK also supports maxTotalTimeout for an absolute deadline, but I recommend not setting it by default since users explicitly want long-running tasks to work

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[m-ibm]

I made the suggested change directly in my extension.js (v3.36.7 ... cannot upgrade to v3.37+).
This didn't work, I am still getting a timeout error.

[mrubens]

Have you tried changing the timeout in the MCP server configuration? Does that not work, or is the issue that the max of 1 hour is not long enough?