url-to-pdf-api
url-to-pdf-api copied to clipboard
alvarcarto
random errors when rendering pdf from html via POST
First - thank you so much for creating and working on this project.
I've deployed to Heroku. Most of the time pdf is generated, sometimes there is an error and entire node server crashes.
Here is the log: url_to_pdf_api_error-01-25-2018.log
Is there a good way to debug this problem? Currently it crashes around ~20% of the time. I was running on "hobby" initially, but had same results on 1x and 2x instance types.
I'm also seeing this issue, but only under docker/linux. On the mac os host it works fine.
This seems to be an issue with downstream dependencies. If I npm shrinkwrap jimaek/url-to-pdf-api and include here, it works fine.
I've done so here: https://github.com/AudaxHealthInc/url-to-pdf-api/commit/41dc56c3c028b0dcc643cf83136e3e21b1500fd7
Seems like this is the error: https://github.com/websockets/ws/issues/1256
I ended up upgrading ws ("ws": "^4.0.0"), puppeteer( "puppeteer": "^1.0.0") and looks like that solved the problem.
@faliev Do you mind sharing how you upgraded "ws" to 4.0.0? I'm not very familiar with npm and puppeteer 1.0.0 is using ws 3.3.3. If I add "ws": "^4.0.0" to package.json dependencies, I get both versions in my package-lock.json, where puppeteer is still using ws 3.3.3. Thanks.
@faliev Can you please share how did you upgrade the ws module? I am getting the same issue as @jjculber
yeah @htmldoug or @faliev can you guys share a branch/repo where this is currently working we can fork from pretty please?
@theinventor https://github.com/AudaxHealthInc/url-to-pdf-api/commit/41dc56c3c028b0dcc643cf83136e3e21b1500fd7 works, though that's a big hammer. @faliev's solution seems more targeted.
~i tried to fix this with upgrading - i thought it worked, then i didn't, now i know upgrading the ws library and puppeteer does not actually fix this, although the error is less often that's for sure... fyi see #60~
scratch that, but the bump of ws does have to be in puppeteer itself... (unless running these iterations through newman fails over the weekend, in which case i will laugh)
Fork puppeteer and update it’s ws dep to v4, use that fork within this package.json. Fyi
@eriktrom Thanks. But i also change the waitUntil to 'networkidle2' in the pdf-core.js file
@crakoucas - yeah - u can use waitUntil: 'networkidle0' as well, i don't recall the exact difference anymore, might want to double check why there are 2 values for this property... fyi
also, either way, with this puppeteer update, the logging when NODE_ENV=production is insane (seems borked, logs the source file - this doesn't happen on mac in development + http allow mode) <-- main reason i never made a pr for the changes discussed here, if someone finds the fix, this issue could be closed via easy pr (after updating puppeteer itself upstream)
Puppeteer has now been upgraded to 1.6.0 in master. Also published in the demo app running in Heroku. Can someone verify if the issues are fixed?
Would you consider adding a package-lock.json or accept a PR for this?
We had problems installing a working version due to this issue and this could be mitigated by locking the dependency versions.
As of today I am still getting the error below as described in this issue with cf1b1b65ebe7ad73832e619f781b34684907b151 and POST:
2019-05-07T12:54:09.234201954Z events.js:183
2019-05-07T12:54:09.234227129Z throw er; // Unhandled 'error' event
2019-05-07T12:54:09.234232336Z ^
2019-05-07T12:54:09.234238544Z
2019-05-07T12:54:09.234242019Z Error: read ECONNRESET
2019-05-07T12:54:09.234245079Z at TCP.onread (net.js:622:25)
is there one of the forks being more stable?
Puppeteer is now 1.14.0 in master, which also fixes the rendering issues with large HTML contents in body. I have no way to test if this improves these random errors. Could someone try and test?