Session wedges after navigating wiki.adom.inc/skills listing: 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 identically on AdomLapper 2026-07-26: (1) browser_open_window to any wiki.adom.inc page (renders fine). (2) browser_navigate that session to https://wiki.adom.inc/skills (the SECTION LISTING). (3) The next browser_eval times out, and from then on EVERY verb on that session (browser_eval, browser_list_tabs) returns status:timeout / 'Request timed out' (timeoutSeconds 10) indefinitely. A NEW session opened afterwards works, so the wedge is per-session/tab, not the bridge process. Individual page routes like /adom/adom-wiki-skillpack render and eval fine in the same setup; only the /skills listing triggers it. Verbatim failing response: {"durationMs":10002,"error":"Request timed out","ok":false,"status":"timeout","timeoutSeconds":10}.

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.