playwright-go
playwright-go copied to clipboard
Playwright-go randomly hangs?
Hi Everyone,
Maybe I'm alone on this, but I found that the latest playwright-go release seems to hang randomly once in a while for me. So if I have an app which is called, does some automation / work, then shuts down (maybe after an hour?), and is called again in a bash script loop continuously, sometimes everything locks up.
When this happens, my go program doesn't move to the next statement (whatever that might be) and the browser window doesn't appear to be doing anything. In some cases, it isn't even visible anymore (crash perhaps?). Killing the firefox processes I found doesn't seem to make program execution continue, and eventually get a defunct playwright-go process which becomes a zombie.
Is this something anyone else has experienced with the new build?
Just another observation: When Node.js dies underneath Playwright-go, it usually just prints out an error to console like this:
if (!value) throw new Error(message || 'Assertion error');
^
Error: Assertion error
at assert (/home/user/.cache/ms-playwright-go/1.35.1/package/lib/utils/debug.js:29:21)
at FrameManager.frameAttached (/home/user/.cache/ms-playwright-go/1.35.1/package/lib/server/frames.js:104:25)
at FFPage._onFrameAttached (/home/user/.cache/ms-playwright-go/1.35.1/package/lib/server/firefox/ffPage.js:175:30)
at FFSession.emit (node:events:513:28)
at /home/user/.cache/ms-playwright-go/1.35.1/package/lib/server/firefox/ffConnection.js:204:41
Node.js v18.16.0
After which, your go application just dies because it never gets control again (and ends up waiting for something forever?). Because this isn't easy to reproduce (Except to let your automation app run in a loop until it happens), I can't tell at which place we're locking up.
Perhaps if tracking down the initial problem is too hard due to not having a reliable test case, maybe we could track down all the areas external calls to playwright are being made so we can detect deadlock states and just kill/throw a proper error when something takes too long? At least then, the user has recourse to deal with that error rather than having an app hang indefinitely. AFAIK, I think this has to be done on the playwright-go side, since the user has no control of this when calling the library.
There are indeed deadlock issues that are difficult to reproduce. Could you please test it with this change? The latest commit adds a client-side timeout for events with a timeout parameter.
Just another observation: When Node.js dies underneath Playwright-go, it usually just prints out an error to console like this:
if (!value) throw new Error(message || 'Assertion error'); ^ Error: Assertion error at assert (/home/user/.cache/ms-playwright-go/1.35.1/package/lib/utils/debug.js:29:21) at FrameManager.frameAttached (/home/user/.cache/ms-playwright-go/1.35.1/package/lib/server/frames.js:104:25) at FFPage._onFrameAttached (/home/user/.cache/ms-playwright-go/1.35.1/package/lib/server/firefox/ffPage.js:175:30) at FFSession.emit (node:events:513:28) at /home/user/.cache/ms-playwright-go/1.35.1/package/lib/server/firefox/ffConnection.js:204:41 Node.js v18.16.0After which, your go application just dies because it never gets control again (and ends up waiting for something forever?). Because this isn't easy to reproduce (Except to let your automation app run in a loop until it happens), I can't tell at which place we're locking up.
Perhaps if tracking down the initial problem is too hard due to not having a reliable test case, maybe we could track down all the areas external calls to
playwrightare being made so we can detect deadlock states and just kill/throw a proper error when something takes too long? At least then, the user has recourse to deal with that error rather than having an app hang indefinitely. AFAIK, I think this has to be done on theplaywright-goside, since the user has no control of this when calling the library.
Well, I'm writing because I think it's worth mentioning, I'm facing with exact same issue on latest official playwright (nodejs) library using firefox connection. It just randomly stops, or kills entire application. Also you can't reproduce it on purpose. So, something must be wrong with main logic-flow. I mean, it's not specific to golang port.