fix: bound page CDP calls with a timeout; recover handler panics#56
Merged
Conversation
Page CDP calls used p.ctx — a context.Background()-derived context with no deadline — so a call blocked until the connection closed. A hung Chrome (or a handler the watchdog abandoned on timeout) wedged every subsequent operation and held the session lock indefinitely. Each call now carries a per-call deadline (the session timeout, falling back to the CDP default), so a stuck call fails and releases the lock instead of hanging. This also bounds the watchdog's abandoned-goroutine problem to the session timeout. The MCP watchdog ran handlers in a goroutine but never recovered panics, so the session helper's panic when Chrome can't launch (or any handler panic) crashed the whole server. The watchdog now recovers into a structured SCOUT_PANIC error envelope, covering all tool handlers at one point. Tests: a new watchdog test asserts a panicking handler yields an error response instead of aborting; the full integration suite passes against Chrome under -race with the per-call timeout (no spurious timeouts). Scout review batch: findings #6 (page-call timeout, HIGH) and the handler-panic MEDIUM; also bounds #7 (watchdog cancellation). Claude-Session: https://claude.ai/code/session_01QKTcmXFTKoTQr7mB3HCuHZ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Page CDP calls had no timeout (HIGH)
p.callusedp.ctx— acontext.Background()-derived context with no deadline — so a call blocked until the connection closed. A hung Chrome, or a handler the watchdog abandoned on timeout, wedged every subsequent operation and held the session lock indefinitely.Each call now carries a per-call deadline (the session timeout, falling back to
cdp.DefaultCallTimeoutwhen unset), so a stuck call fails and releases the lock instead of hanging. This also bounds the watchdog's abandoned-goroutine problem (finding #7) to the session timeout — a full cancellation-propagation fix would need threadingctxthrough everySessionmethod; the timeout gets the practical protection without that churn.Watchdog didn't recover handler panics (MEDIUM)
The watchdog ran handlers in a goroutine but never recovered panics — so the session helper's
panic(...)when Chrome can't launch (or any handler panic) crashed the whole MCP server. It now recovers into a structuredSCOUT_PANICerror envelope, covering all 87 tool handlers at one point. The buffered result channel keeps recovery non-blocking even if the watchdog already timed out and abandoned the goroutine.Tests
-racewith the per-call timeout — no spurious timeouts in real operations.Scout deep-review batch: page-call timeout (HIGH) + handler-panic (MEDIUM); bounds the watchdog-cancellation finding.
https://claude.ai/code/session_01QKTcmXFTKoTQr7mB3HCuHZ