Skip to content

Conversation

@roomote
Copy link
Contributor

@roomote roomote bot commented Sep 10, 2025

Description

This PR fixes an issue where MCP tool response times that exceed 1 minute were timing out at 30 seconds instead of respecting the user-configured timeout value.

Problem

The user reported in #7836 that their MCP tool response time exceeds 1 minute, but when they set a 1-minute timeout in the configuration, it was still timing out at 30 seconds. This was happening because the timeout configuration was only being applied to the callTool method, while other MCP operations (readResource, fetchToolsList, fetchResourcesList, fetchResourceTemplatesList) were using the default 30-second timeout from the MCP SDK.

Solution

  1. Added timeout parameter to all MCP client requests:

    • readResource method
    • fetchToolsList method
    • fetchResourcesList method
    • fetchResourceTemplatesList method
    • callTool method (already had it)
  2. Refactored timeout extraction logic:

    • Created a helper method getTimeoutFromConnection to reduce code duplication
    • Applied the helper method to all 5 locations where timeout configuration is needed

Changes

  • Modified src/services/mcp/McpHub.ts to ensure all MCP client requests respect the configured timeout
  • Extracted repeated timeout parsing logic into a reusable helper method for better maintainability

Testing

  • All existing tests pass ✅
  • The timeout configuration now properly applies to all MCP operations

Fixes #7836


Important

Fixes timeout issue in MCP client requests by applying user-configured timeout to all relevant methods in McpHub.ts.

  • Behavior:
    • Ensures all MCP client requests (readResource, fetchToolsList, fetchResourcesList, fetchResourceTemplatesList, callTool) respect user-configured timeout.
    • Default timeout is 60 seconds if parsing fails.
  • Refactoring:
    • Introduces getTimeoutFromConnection helper method in McpHub.ts to extract timeout configuration.
    • Applies getTimeoutFromConnection to all relevant methods to reduce code duplication.
  • Testing:
    • All existing tests pass, confirming timeout configuration applies correctly.

This description was created by Ellipsis for c76fbde. You can customize this summary. It will automatically update as commits are pushed.

- Added timeout parameter to readResource method
- Added timeout parameter to fetchToolsList method
- Added timeout parameter to fetchResourcesList method
- Added timeout parameter to fetchResourceTemplatesList method

Previously, only the callTool method was using the configured timeout,
causing other MCP operations to use the default 30-second timeout
instead of the user-configured value.

Fixes #7836
- Created getTimeoutFromConnection helper method to reduce code duplication
- Applied helper method to all 5 locations where timeout is extracted
- Improves maintainability and reduces repetitive code
@roomote roomote bot requested review from cte, jr and mrubens as code owners September 10, 2025 02:29
@dosubot dosubot bot added size:M This PR changes 30-99 lines, ignoring generated files. bug Something isn't working labels Sep 10, 2025
Copy link
Contributor Author

@roomote roomote bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

const parsedConfig = ServerConfigSchema.parse(JSON.parse(connection.server.config))
return (parsedConfig.timeout ?? 60) * 1000
} catch (error) {
console.error("Failed to parse server config for timeout:", error)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this error handling approach intentional? The helper logs errors but doesn't propagate them, defaulting to 60 seconds instead. While this provides resilience, callers might benefit from knowing when config parsing fails. Consider whether this silent fallback is the desired behavior for all use cases.

} catch (error) {
console.error("Failed to parse server config for timeout:", error)
// Default to 60 seconds if parsing fails
return 60 * 1000
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default timeout of 60 seconds appears here and in the original callTool implementation. Could we extract this to a named constant like DEFAULT_TIMEOUT_SECONDS = 60 at the class level? This would make it easier to maintain and modify the default timeout across the codebase.

* @param connection The MCP connection to get timeout from
* @returns The timeout in milliseconds, defaults to 60000ms if parsing fails
*/
private getTimeoutFromConnection(connection: McpConnection): number {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding explicit return type annotation for better type safety:

Although TypeScript can infer it, explicit typing improves code clarity and catches potential type mismatches earlier.

// Default to 60 seconds if parsing fails
return 60 * 1000
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good refactoring! This helper method effectively reduces code duplication across all MCP client request methods. Consider adding unit tests for this helper to ensure it handles edge cases like invalid JSON, missing timeout field, and various error scenarios.

@hannesrudolph hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Sep 10, 2025
@daniel-lxs
Copy link
Member

Issue needs info

@daniel-lxs daniel-lxs closed this Sep 10, 2025
@github-project-automation github-project-automation bot moved this from New to Done in Roo Code Roadmap Sep 10, 2025
@github-project-automation github-project-automation bot moved this from Triage to Done in Roo Code Roadmap Sep 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. size:M This PR changes 30-99 lines, ignoring generated files.

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

How to set the timeout configuration

4 participants