Follow-up to https://github.com/matrix-org/matrix-public-archive/pull/51
Better `child_process` error handling for a couple scenarios with the finger pointing at it 👉
Also make sure we handle all of these scenarios:
1. Child process fork script throws an `uncaughtException` or `unhandledRejection`
- These are captured and serialized back to the parent and stored in `childErrors` and exposed if we never get a successful rendered HTML response.
2. Child process fails to startup
- Render process is rejected in the `child.on('error', ...` callback
3. 👉 Child process times out and is aborted
- Render process is rejected in the `child.on('error', ...` callback and any `childErrors` encountered are logged
4. 👉 Child process fork script throws an error in scope of in `process.on('message', async (renderOptions) => {`
- Child exits with code 1 and we reject the render process with the error
5. Child process exits with code 1 (error)
- Render process is rejected with any `childError` info
6. Child process exits with code 0 (success) but never sends back any HTML
- We have a `returnedData` data check and any child errors encountered are logged
Split off from https://github.com/matrix-org/matrix-public-archive/pull/43
Listen to `process.on('uncaughtException', ...)` and handle the async errors ourselves so it no longer fails the child process.
And if the process does exit with status code 1 (error), we have those underlying errors serialized and shown.
`renderHydrogenToString` is a pure function (probably) which means it will give the same output given the same input. This means, that if we give it a certain input and an error occurs, we should be able to reproduce it again if we have the arguments. This PR exposes those arguments in the logged error so we can investigate what's going wrong.
Added so we can investigate https://github.com/matrix-org/matrix-public-archive/issues/34 better and reproduce locally.
Eric Eastwood