You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the intermittence, I've split that into 3 separate await lines to insert console.debug() lines after each.
Based on those debugging statements, I've seen occurrences of either Runtime.enable() not resolving or Network.enable() not resolving.
Before I consider trying to handle this as a timeout problem (to potentially retry), I'm seeking for suggestions/ideas/help on how to debug this further.
I couldn't find past reports regarding such intermittent problem on GitHub or on SO.
The version of Node.js used is 12.16.3 on an AWS EC2 t2-medium instance.
The headless Chromium version is 706915 (installed as part of [email protected] but I don't use anything from puppeteer itself). It is running on the same host as Node.js. It is started just before the Node.js process is started and there's no code that restarts the Chromium process. Newer precompiled Chromium instances don't work on this AWS EC2 (Linux ip-xxx-xxx-xxx-xxx 4.9.85-38.58.amzn1.x86_64 #1 SMP Wed Mar 14 01:17:26 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux).
All the HTMLs are on the same host, too, passed on to htmlPdf.create() as file://name.html. The Node.js process + Chromium process + input files are all on the same host.
And, to avoid making the EC2 instance be too overloaded, the Node.js application throttles so that there are, at the most, 10 tabs the headless Chromium needs to convert at any particular time, using the technique involving Promise.race().
I haven't been able to come up with a small test program that reproduces the intermittent problem.
The text was updated successfully, but these errors were encountered:
My Node.js application uses html-pdf-chrome to convert thousands of HTMLs to PDFs.
Intermittently (after several hours), the
Promise.all()
call inbeforeNavigate()
(https://github.com/westy92/html-pdf-chrome/blob/master/src/index.ts#L106-L110) does not resolve. As a result, my Node.js dependent that callshtmlPdf.create()
also got stuck.Due to the intermittence, I've split that into 3 separate await lines to insert
console.debug()
lines after each.Based on those debugging statements, I've seen occurrences of either
Runtime.enable()
not resolving orNetwork.enable()
not resolving.Before I consider trying to handle this as a timeout problem (to potentially retry), I'm seeking for suggestions/ideas/help on how to debug this further.
I couldn't find past reports regarding such intermittent problem on GitHub or on SO.
The version of Node.js used is 12.16.3 on an AWS EC2 t2-medium instance.
The headless Chromium version is 706915 (installed as part of [email protected] but I don't use anything from puppeteer itself). It is running on the same host as Node.js. It is started just before the Node.js process is started and there's no code that restarts the Chromium process. Newer precompiled Chromium instances don't work on this AWS EC2 (Linux ip-xxx-xxx-xxx-xxx 4.9.85-38.58.amzn1.x86_64 #1 SMP Wed Mar 14 01:17:26 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux).
All the HTMLs are on the same host, too, passed on to
htmlPdf.create()
asfile://name.html
. The Node.js process + Chromium process + input files are all on the same host.And, to avoid making the EC2 instance be too overloaded, the Node.js application throttles so that there are, at the most, 10 tabs the headless Chromium needs to convert at any particular time, using the technique involving
Promise.race()
.I haven't been able to come up with a small test program that reproduces the intermittent problem.
The text was updated successfully, but these errors were encountered: