Add documentation: unhandledrejection when "Unable to restart chrome."

[dustinmcbride]

Issue
When using SingleBrowserImplementation and chrome gets into a state in which it cannot be restarted then the error does not bubble which causes a javascript unhandledrejection. Since there is no way to catch this it forces consuming code into a dead end. Using node v8.11.1

Reproduction:
I have not found a way to put chrome into such a state that it cannot be restarted so the repro hack is to throw an error where puppeteer-cluster tries to re-launch the browser (SingleBrowserImplementation.js:41)

Steps
1.) Modify code to throw an error
2.) Kill all chromium instances with killall Chromium
3.) Execute task

Current Work Around
The only workaround I have found is using a node manager and then crash the service when this issue occurs
process.on('unhandledRejection', up => { throw up })

[thomasdondorf]

You are right, if the library is not able to restart the browser it throws an error that cannot be caught at the moment.

When I implemented I did not want to use the "normal" taskerror event as this is used for recoverable errors that happen inside the page. Also, this error indicates that something is deeply wrong (not enough memory, CPU, disk space, etc.) as otherwise the library should be able to restart the browser.

What would be the best option here? Maybe introduce an error event to signal that the library is not able to recover?

Btw, thanks for taking the time and making nicely formatted issue :)

[iamEAP]

Found myself here as a result of running Puppeteer Cluster in resource-constrained PaaS/IaaS environments and running into this error intermittently.

I like the idea of a different error type from taskerror to signal an unrecoverable error. It would be tidier than the workaround by OP; first-class support for this would also justify documentation about it, which would be helpful!

This would make it easier..

• In larger, more formal systems, to detect and expose the fact that a node in a (container) cluster was "unhealthy," which would allow the parent orchestration framework to route traffic away and remediate.
• In smaller, "DIY" systems, to detect an unrecoverable state, gracefully handle shut-down tasks in context, and end the process (leaving remediation to a container restart policy or similar)