Session wedges after navigating wiki.adom.inc/skills: all verbs time out

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Closed bug report

John Lauer · 15d ago ·closed by John Lauer

Repro (hit twice, both times identical): browser_open_window to any wiki.adom.inc page, then browser_navigate the session to https://wiki.adom.inc/skills (the section LISTING). The next browser_eval times out, and afterwards EVERY verb on that session (browser_eval, browser_list_tabs) returns {"status":"timeout","error":"Request timed out","timeoutSeconds":10} indefinitely. Other sessions opened later work fine, so it is the session/tab that wedges, not the bridge process. Verbatim failure: {"_hint": "status:timeout - the desktop didn't respond in time...", "durationMs": 10002, "error": "Request timed out", "ok": false, "status": "timeout", "timeoutSeconds": 10}. Individual page routes (/adom/) render fine in the same setup; only the /skills listing triggers it. Bridge version: whatever shipped with AD 1.9.191-era on AdomLapper, 2026-07-26.

1 Reply

John Lauer · 11d ago

Cannot reproduce as of v1.9.221 — ran your exact repro and the session stayed healthy.

1. browser_open_window  → wiki.adom.inc/adom/adom-desktop-puppeteer-bridge   ok, eval fine
2. browser_navigate     → https://wiki.adom.inc/skills  (the section listing)  ok
3. browser_eval  x3     → 2, 2, 2      (issue says these time out forever)

Every verb the issue named as wedged now works on that session:

Verb	Result
`browser_eval`	`{url: "/skills", ready: "complete", links: 179}`
`browser_list_tabs`	1 tab
`browser_screenshot`	OK
6 rapid evals (the tight-loop pattern from #16)	6/6

Most likely what fixed it (none of it aimed at this issue specifically, which is why I'd rather you sanity-check than take my word):

v1.9.163 — the CDP flood fix. The console mirror wrote every page message synchronously to stdout and a requestfailed listener firehosed the shared CDP socket. A heavy listing page like /skills (179 links, React) is exactly the shape that saturated it, and once that socket was jammed every verb on the session timed out — which matches your symptom precisely, including that a new session worked while the old one stayed dead.
v1.9.172 — every per-window CDP read is now timeout-bounded, so one slow page can't hang a verb indefinitely.
v1.9.176/178 — crashed renderers are detected and auto-recovered instead of silently wedging the tab.

#26 and #27 are the same report filed twice, so closing both.

Reopen if you see it again — and if you do, browser_deps and the _degraded flag on browser_status will now tell us whether it's a jammed socket or something new.