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

Proper servant-server exception handling for warp/wai #1192

symbiont-joseph-kachmar opened this issue Jul 3, 2019 · 0 comments

Proper servant-server exception handling for warp/wai #1192

symbiont-joseph-kachmar opened this issue Jul 3, 2019 · 0 comments


Copy link

@symbiont-joseph-kachmar symbiont-joseph-kachmar commented Jul 3, 2019

I spent some time reading through issue #309 and the associated discussions in yesodweb/wai#496 and PR #954 about how servant-server appears to incorrectly handle exceptions with respect to how wai/warp expects to operate.

The unfortunate side effect of this behavior is that any uncaught exceptions within a Servant application will not be registered by any wai middleware as a 500 exception, which can seriously negatively impact user experience around automated logging, metrics tracking, etc.

As far as I can tell, the solution proposed in #309 around deeply evaluating Responses in toApplication before creating a ResponseReceived (to provide to wai) won't work for ensuring that any impure exceptions in thunks are caught (Response cannot have a valid NFData instance to the best of my knowledg).

The machinery for forcing evaluation, catching exceptions, and generating correct wai Responses would have to live somewhere else in Servant, probably using a similar combination of techniques as to what Yesod uses:

I'm opening a new issue since it seems as if the old ones have languished a bit, and the strategies for handling this problem outlined in them don't appear to actually address the core issue here.

Does anyone have thoughts on what a good architecture for this might look like?

Perhaps some pointers towards code paths within Servant that would allow us to implement the correct behavior, even just as an opt-in for users who want to ensure that middleware operates as-expected?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.