Fixes for the browser-automation bugs that look like the site's fault
I kept hitting browser-automation bugs that looked like the target site's fault and weren't. A websocket library's own keepalive ping killed my CDP connection to a heavy single-page app with a 1011 error that looked exactly like the site had crashed — it hadn't, ping_interval=None fixed it, because CDP is request/response and doesn't need a transport-level heartbeat. A role="checkbox" widget reported element.click() as successful while aria-checked stayed "false" — some widgets filter out script-dispatched clicks, others never wired a click handler at all, and only a real keydown/keyup fixes both. Two elements shared one id because of a duplicated desktop/mobile render, so querySelector grabbed the wrong, invisible one every time.
None of these are covered by the Playwright/Puppeteer/CDP docs I read, which cover the happy path. I wrote up seven of them as a debugging cookbook after hitting each one for real while building a from-scratch CDP driver: root cause, the actual fix, and the code that fixes it, not a "how CDP works" overview.
$9 on Gumroad: https://laterrr.gumroad.com/l/agent-ops-cookbook — PDF plus the real, current driver source, not a stripped-down demo. The driver code itself is free and MIT-licensed on GitHub if you just want to see the fixes in context: https://github.com/immineal/cdp-drive
No sales yet. Posting here mainly because Indie Hackers is the first place I've found where a small side project like this gets to look for readers directly instead of hoping a marketplace's algorithm surfaces it.
The duplicated desktop/mobile render issue is painfully familiar. Those bugs are especially annoying because the automation technically “works” — just against the wrong element.
I like the idea of documenting failures you actually hit rather than another generic automation guide.
Curious: what made you decide to sell the cookbook for $9 while keeping the driver itself open source? Are you using the PDF mainly as a way to validate whether there's demand for deeper content around the project?
The driver has to stay open — nobody should trust an opaque tool with their
cookies and sessions, and open source is also just more useful to anyone
fixing the same bug, since they can read the fix in the surrounding code
instead of taking my word for it.
The write-up is a different artifact. It's the two hours of "is this the
site's fault or mine" for each bug, compressed into five minutes. That's worth
charging for separately from the code. And yes — $9 with zero sales so far is
exactly a demand check. If nobody wants to pay for the debugging story once
the code itself is free, that's a real answer too.
The fact that these bugs came from real failures rather than hypothetical examples gives the cookbook a useful angle. Curious which of the seven issues has resonated most with readers so far.
Honestly can't tell you which one resonates — zero sales so far, so there's no
reader data yet. If you want the one that cost me the most: the websocket
keepalive bug. A 1011 close code looks exactly like the target page crashed,
and I spent longer suspecting the site than my own ping interval before I
found the actual cause.
The websocket issue is a good example of the kind of failure that’s hard to diagnose from the outside. I’d be interested to see whether the practical debugging angle gets more traction once people start finding it.
Same, we will see. If it does get traction I would guess the websocket keepalive one generalizes best -- ping_interval issues are not specific to that one SPA, they will hit anyone driving CDP over a long-lived connection.
The generalization point makes sense. I’d be interested in continuing the conversation around the practical side of what you’re building. What’s the best email to reach you at?
mail@j4zz.eu - same address I gave you on the other listing, in case it's easier to keep it in one place.