Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors from Axios are treated as unhandled exceptions and crash the application #24

Closed
TheAppleFreak opened this issue Apr 5, 2023 · 2 comments · Fixed by #25
Closed
Labels

Comments

@TheAppleFreak
Copy link
Owner

@jbojbo reached out to me on Twitter with an interesting issue where if for whatever reason Axios throws an error, it'll be treated as an unhandled exception by Node and will cause the entire application to crash. Among other things, this could happen if Slack was to return an API error such as a 429 Too Many Requests. I'd noticed this issue in my own applications in the form of unpredictable and intermittent crashes, but I had never actually identified the issue myself.

The source of the issue boils down to where the post request to the webhook is actually made, but what confuses me is that there is an error handler on that already. Why is Node treating it as an unhandled error?

@TheAppleFreak TheAppleFreak changed the title Consuming applications crash when Axios returns an error Errors from Axios are treated as unhandled exceptions and crash the application Apr 5, 2023
@TheAppleFreak
Copy link
Owner Author

Toying around with this, and I think the this.emit("error", err) line might be the culprit? While testing, I found that throwing an error in the same place but commenting out the emit resulted in it just working properly, so... maybe that requires its own error handler? Or maybe the error needs to be handled a bit differently. Reading up on the Winston docs to see how emit("error") should be used best, if at all.

Checked a few other transport plugins similar to this one as well to see how they handle it, and the results are largely "we don't do that." winston-graylog2, humio-winston, logdna-winston, newrelic-winston don't have any error handling on send and don't include the emit("error") bit at all, and winston-datadog explicitly ignores errors altogether.

@TheAppleFreak
Copy link
Owner Author

Ah, so that's what it does.

Think the best approach would be to put that behind a flag that you'd toggle in the constructor settings, so if you want to be able to handle Slack errors you can do so. Default will be false to match the expected behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
1 participant