Skip to content

Fix stale process cache after spawning bridge process#167

Merged
jancurn merged 1 commit intomainfrom
claude/fix-windows-e2e-tests-juDka
Apr 15, 2026
Merged

Fix stale process cache after spawning bridge process#167
jancurn merged 1 commit intomainfrom
claude/fix-windows-e2e-tests-juDka

Conversation

@jancurn
Copy link
Copy Markdown
Member

@jancurn jancurn commented Apr 15, 2026

Summary

This PR fixes an issue where the Windows tasklist cache used by isProcessAlive() could return stale results after spawning a new bridge process, causing spurious double-restart failures.

Changes

  • Added invalidateProcessAliveCache() export in src/lib/utils.ts: New public function to clear the Windows tasklist cache and reset its TTL timer
  • Call cache invalidation after spawn in src/lib/bridge-manager.ts: Immediately after spawning the bridge process, invalidate the cache so subsequent isProcessAlive() checks can observe the newly spawned PID instead of relying on a pre-spawn snapshot

Implementation Details

The Windows process alive check uses a 2-second TTL cache to avoid excessive tasklist command invocations. However, when a new bridge process is spawned, the cache may still contain a snapshot from before the spawn, causing isProcessAlive() to incorrectly return false for the new PID. This triggered spurious double-restart behavior in health checks that run immediately after spawning.

By invalidating the cache right after spawning, we ensure the next isProcessAlive() call will fetch a fresh tasklist that includes the newly spawned process.

https://claude.ai/code/session_014w5QYdwZKHA5REd2pTEXwP

On Windows, `isProcessAlive()` uses a 2-second cached `tasklist` snapshot
populated when `stopBridge()` runs. When `restartSession` subsequently
spawns a new bridge, the new PID is not in the cache, causing
`ensureBridgeReady()` to misclassify the freshly spawned bridge as dead
and trigger a spurious double-restart via `restartBridge()`. Unlike the
explicit `restartSession` path, `restartBridge` passes `mcpSessionId` for
resumption, so the second bridge silently resumes the old MCP session
and `sessions.json` never records a new session ID.

This caused two E2E tests to fail on Windows:

  - sessions/mcp-session #6: mcpSessionId unchanged after explicit restart
  - sessions/restart #9: `.capabilities` missing from `restart --json`

Fix by resetting the tasklist cache immediately after spawning the bridge
so the next `isProcessAlive()` check runs a fresh `tasklist`. The only
`spawn()` call in src/ is in `startBridge`, so one invalidation site
covers every bridge startup path.

https://claude.ai/code/session_014w5QYdwZKHA5REd2pTEXwP
@jancurn jancurn merged commit 89ec333 into main Apr 15, 2026
6 checks passed
@jancurn jancurn deleted the claude/fix-windows-e2e-tests-juDka branch April 15, 2026 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants