Dealing with panics
- Dominant language
- Rust
- Stars
- 5.1k
- Forks
- 329
- PR merge metrics
- No merged PRs in 30d
Description
Currently Tide doesn't provide any way to deal with panics in handlers, these just unwind up to the executor and (at least in the case of Tokio) kill the executors thread. During the unwinding the TCP connection is dropped and the client gets something like `The connection was reset`. The application as a whole just keeps running (I'm not sure what happens with other requests currently being handled on the same worker thread).
My first thought on dealing with this is having a middleware that uses `catch_unwind` to catch the panic and return a minimal 500 to the client. (I have prototyped this and it works very easily).
The other part of this is that when I encountered it I had locked a `Mutex` stored in the `State`, this subsequently started returning `PoisonError` on access so my application was effectively dead. Maybe when a panic is encountered it should be proxied through to the future returned by `serve` and resumed on the main thread to try and kill the entire application. Alternatively this could be dealt with at the application level using "health checks" with support from a service coordinator (like Kubernetes). Since it depends on usecase it may make sense to provide middleware supporting different options and allow the user to choose.
Contributor guide
Assessment
This issue has not been assessed yet.