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
fix(server): error in pre handler triggers after event #1500
Conversation
test/server.test.js
Outdated
@@ -2957,3 +2957,22 @@ test('calling next twice should throw', function (t) { | |||
t.ifError(err); | |||
}); | |||
}); | |||
|
|||
test('aborting pre should still call after', function (t) { |
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.
Can we put this at/around L2312 to group it with the other pre handler test that is testing next(false)
? And maybe rename the test to next(err) should still trigger after event
to be a little more precise since "abort" doesn't really mean much in context of existing restify docs or nomenclature.
lib/server.js
Outdated
self._finishReqResCycle(req, res); | ||
// Like with regular handlers, if we are provided an error, we | ||
// should abort the middleware chain and fire after events. | ||
if (err !== undefined) { |
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 behavior is slightly inconsistent compared to how its implemented in the use
chain, where we are explicitly checking for false
or err
. The result is that calling return next({})
could trigger an early exit in pre where it wouldn't in use. I don't mind revisiting what nexting with a POJO means, but probably worth tackling in a separate PR?
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.
Yup, was on the fence about this. The explicitness bit us in the butt here 😄 so I erred on the side of assuming everything was a cause to abort the chain. Though I guess if someone were to do next(true)
or next(null)
this would drop the chain which may not be desirable.
Awesome - great work tracking this down. 🎉 |
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.
Looks good, I'm just confused about dropping a code fragment.
return; | ||
} | ||
|
||
if (!err) { |
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.
How come this got dropped? I think if you remove this there is the edge case where the "err" object is not false or a function?
Currently, aborting a middleware chain inside a
pre
handler will cause restify to drop the chain on the floor. This results in theafter
event not firing.An effect of this is that
after
handlers do not get access to requests rejected by throttles.This PR fixes that.