MCP stdio session readiness timeout still hardcoded at 30s with no settings override (configurability gap not addressed by #14161/#14214)

[mjobrien05]

Bug Description

MCPSessionManager._create_stdio_session (src/lfx/src/lfx/base/mcp/util.py) guards session readiness with a hardcoded 30-second asyncio.wait_for, with no settings override anywhere. This sits right next to mcp_server_timeout (src/lfx/src/lfx/services/settings/groups/mcp.py, default 20s), which is a configurable setting covering the overall tool-list call on the same path.

#14161 / #14214 already fixed the resource-leak consequence of these two timeouts disagreeing (the outer 20s firing before the inner 30s could leak the spawned subprocess) — but that fix was explicit about scope, per the PR description: "It intentionally preserves the existing timeout budgets, avoiding a shorter cold-start window for MCP servers." The underlying configurability gap itself is still open: there is still no way to raise the STDIO session's own readiness budget past 30s, and no way to make it consistent with a custom mcp_server_timeout value in either direction.

Concretely, this still leaves a real failure mode for anyone with a slow-starting local MCP server (e.g. one with a heavier npx/node cold start): raising LANGFLOW_MCP_SERVER_TIMEOUT above 30s does not help, because the inner session-readiness wait still caps at the hardcoded value regardless of what the outer setting is configured to.

Reproduction

1. Configure an MCP server (stdio transport) with a cold-start time longer than 30s but shorter than a raised LANGFLOW_MCP_SERVER_TIMEOUT.
2. Set LANGFLOW_MCP_SERVER_TIMEOUT=60.
3. Attempt to connect.

Expected: the connection succeeds within the configured 60s budget.
Actual: Timeout waiting for STDIO session ... to initialize at ~30s, regardless of the higher configured value.

Expected behavior

Expose the STDIO (and Streamable HTTP, which has the same hardcoded-30s pattern in _create_streamable_http_session) session-readiness timeout as a setting, ideally defaulting to (or derived from) mcp_server_timeout so the two stay consistent without requiring two separate values to be tuned in lockstep.

Who can help?

No response — related to the area fixed in #14161/#14214, tagging for visibility in case the same reviewers want it.

[hardik47278]

I’d like to work on this issue, @mjobrien05. I can investigate how mcp_server_timeout is propagated to MCPSessionManager, verify the current behavior for both STDIO and Streamable HTTP session readiness, and then add the appropriate configurability and regression tests while keeping the existing timeout semantics intact.

[andifilhohub]

LE-2761

[erichare]

Thanks for the clear report and reproduction. I checked the v1.12.3 tag and the current release-1.12.4 branch: both include the fix from #14936. The stdio session-readiness wait now follows LANGFLOW_MCP_SERVER_TIMEOUT (default 60 seconds) instead of a hardcoded 30 seconds. The Streamable HTTP/SSE session-readiness wait uses that setting as well. The targeted timeout tests pass, and the relevant code is identical in those two refs.

Could you try v1.12.3 with your slow-starting stdio server, setting LANGFLOW_MCP_SERVER_TIMEOUT=60 (or higher if its startup needs more time), and let us know whether it connects? If it still times out, the elapsed time and sanitized logs would help us identify which timeout fired. The fix is also on the 1.12.4 release branch, which has not been tagged yet.

Thanks again for raising this.

[erichare]

#14936 FYI, this is the PR it was fixed in.

[andifilhohub]

So, the fix has been merged.