Support handlers calling res.destroy() to abort sending a response #150
+116
−5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When calling
res.destroy([err])before'finish', shot will currently either do nothing and never return, or reject/throw an unhandled exception.This does not seem desirable. This is fixed in this PR by detecting aborted responses, and exposing such through a new
abortedproperty. Depending on when the abort happens, more or less of theresponsecan be filled in along with it.I don't think this is a breaking change, since it only changes the behaviour of previously failing
inject()calls. It can however affect code that relies on the buggy behaviour. One example is this test from hapi, where inject will now return a value. But the test still passes. In fact all hapi tests still pass.Note that I'm not really a fan of the new
abortedproperty, since you will need to remember to check for it, as the response might otherwise look complete. Ideally this property would only be exposed with an option, and normally just reject with an error. This is however more of a breaking change, and conflicts with how hapi uses this module.