Closed sebastian closed 4 years ago
Just checking - did this cause any failure of subsequent requests? If so, that would be worrying.
Also, is the issue that exploration was already in a failed state and therefore should no longer be running?
Otherwise, it does pretty much what I would expect if the air
server restarts (Connection refused
).
There are a few ways we can deal with this if we catch this kind of exception:
Any preference / thoughts?
Option 2 is my preference. I.e. being more graceful and produce an error that can be reported back to air
upon a request when an unexpected crash happens.
So it crashed the process? Because by default it should just log the exception and return a 500 error with the exception detail. However the server should still be alive to accept further requests.
Quite frankly I don't know. So maybe this isn't a problem at all. Feel free to close. I just noticed there was an unhandled exception and thought it might be useful to report.
Ok. Clearly there is something to be improved since it definitely looks like something terrible happened to the application (fail!!
). I'll keep it open for now until I can check to be sure it doesn't have any wider implications (ie. crashing the system).
Closing this - we have made improvements to error handling and will also be adding sentry to (hopefully) collect better diagnostics.
I restarted the
air
and thecloak
in a middle of a failed exploration (all running locally – no docker) and got the following exception: