-
-
Notifications
You must be signed in to change notification settings - Fork 375
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
Changed error handling logic to stop after error has been handled #497
Changed error handling logic to stop after error has been handled #497
Conversation
Codecov Report
@@ Coverage Diff @@
## master #497 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 20 20
Lines 547 550 +3
Branches 112 113 +1
=========================================
+ Hits 547 550 +3
Continue to review full report at Codecov.
|
Hello @philprime! At first glance, this looks good and more consistent with what is documented here. I am ok for merging this, but I prefer to do it after #504 so that I can release it together with few other pending PRs. Meanwhile, I'd love to get @willfarrell or @dkatavic review as well here :) |
@@ -276,7 +276,7 @@ describe('🛵 Middy test suite', () => { | |||
}) | |||
}) | |||
|
|||
test('If theres an error and one error middleware handles the error, the next error middlewares is executed', (endTest) => { | |||
test('If theres is an error and one error middleware handles the error, the next error middlewares should not be executed', (endTest) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be there
instead of theres
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was merged while inspecting the code, ignore it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did mess up with this one a little. I will do another commit to properly release this on 0.x and also fix this typo. So totally valuable comment :) Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(i will also fix in the port to 1.0)
We should port this one to 1.0.0-beta, realized only now this was targeting master :( |
This fix will be released shortly in 0.35.0 and in 1.0.0-beta.11 |
I am revisiting this in the context of v1 (which includes a http-response-serializer that also works with the default HTTP error handler). This PR breaks the original intended design (and therefore compatibility with some middlewares). As per the docs:
This is needed for instance in the case of the HTTP error handler which will format the error in a correct response for the lambda HTTP integration. If this is combined with the response serializer it must be possible to convert this response to XML or other formats. I will have to revert this on master |
Changed run error middlewares so that it conforms to the behaviour stated in the documentation
middleware2
should not be called.Relevant issues: