Skip to content

fix(mcp): increase preflight timeout and retry initialize - #479

Merged
andresharpe merged 3 commits into
andresharpe:mainfrom
IBondarenko-iwg:fix/mcp-preflight-timeout-473
Jun 11, 2026
Merged

fix(mcp): increase preflight timeout and retry initialize#479
andresharpe merged 3 commits into
andresharpe:mainfrom
IBondarenko-iwg:fix/mcp-preflight-timeout-473

Conversation

@IBondarenko-iwg

@IBondarenko-iwg IBondarenko-iwg commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

Linked issue

Closes #473

Summary of changes

Read-DotbotMcpPreflightLine had a hardcoded 5s timeout introduced in ef80c06. When worktree file copy runs slow under I/O load (~9s), cold pwsh startup for the MCP server exceeds that window — first run fails, retry succeeds because the worktree already exists.

Two fixes in Invoke-WorkflowProcess.ps1:

  • Default TimeoutMs raised from 5 000 → 15 000 ms
  • initialize RPC retries once before failing; logs first failure at Debug level

Testing notes

  1. Start a fresh session (dotbot go) with no existing worktree for the task
  2. Confirm first run completes without initialize_failed error

Checklist

@andresharpe
andresharpe merged commit 6dc4fe2 into andresharpe:main Jun 11, 2026
6 checks passed
@github-project-automation github-project-automation Bot moved this from Inbox to Done in Dotbot Product Backlog Jun 11, 2026
carlospedreira pushed a commit that referenced this pull request Jun 23, 2026
….exe

Claude Code's MCP client uses a short default connection timeout (~5s),
but the dotbot stdio MCP server cold-starts in 12-30s. The per-task
claude.exe spawned its own MCP init before mcp__dotbot__* tools loaded,
making them permanently unavailable for that task session.

Inject MCP_TIMEOUT (60s) and MCP_TOOL_TIMEOUT (30s) into the per-task
process environment, guarded by ContainsKey so operator-set values win.
Independent of the preflight readiness check (PR #479).

Closes #521
carlospedreira pushed a commit that referenced this pull request Jun 25, 2026
Test-DotbotMcpReadiness set DOTBOT_PROJECT_ROOT to the worktree path when
spawning the standalone preflight MCP process. On task retry the worktree's
.control junction can be stale (teardown/re-create is not atomic), so the MCP
server fails to resolve runtime.json and exits before the handshake begins —
the 2-attempt retry loop from #479 cannot help because the process dies
pre-handshake.

This also bypassed #356: Resolve-ProjectRoot returns DOTBOT_PROJECT_ROOT
verbatim when set, skipping git-common-dir detection entirely.

Add an optional -ProjectRoot parameter to Test-DotbotMcpReadiness and pass the
main project root at the call site. The main root always has a stable
.control/ directory, so runtime.json resolution keeps working on retry.
Backward compatible: callers that omit -ProjectRoot fall back to the worktree
path.

Closes #515
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

MCP preflight timeout too tight — fails when worktree file copy is slow

2 participants