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.

Sign up for GitHub

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

Jump to bottom

fix(server): error in pre handler triggers after event #1500

Merged
merged 2 commits into from Sep 19, 2017
Merged

fix(server): error in pre handler triggers after event #1500

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2254ff9
fix(server): error in pre handler triggers after event
Sep 19, 2017
c6a37c2
impl feedback
Sep 19, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 5 additions & 8 deletions lib/server.js
View file
Open in desktop
Expand Up @@ -753,17 +753,14 @@ Server.prototype._handle = function _handle(req, res) {
// run pre() handlers first before routing and running
if (self.before.length > 0) {
self._run(req, res, null, self.before, function (err) {
// check for return false here - like with the regular handlers,
// if false is returned we already sent a response and should stop
// processing.
if (err === false) {
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) {
Copy link
Member

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?

Copy link
Member Author

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.

self._finishReqResCycle(req, res, null, err);
return;
}

if (!err) {
Copy link
Member

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?

routeAndRun();
}
routeAndRun();
});
} else {
routeAndRun();
Expand Down
19 changes: 19 additions & 0 deletions test/server.test.js
View file
Open in desktop
Expand Up @@ -2957,3 +2957,22 @@ test('calling next twice should throw', function (t) {
t.ifError(err);
});
});

test('aborting pre should still call after', function (t) {
Copy link
Member

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.

setTimeout(function () {
t.fail('Timed out');
t.end();
}, 2000);
var error = new Error();
SERVER.pre(function (req, res, next) {
next(error);
});
SERVER.get('/', function (req, res, next) {
t.fail('should have aborted stack before routing');
});
SERVER.on('after', function (req, res, route, err) {
t.equal(err, error);
t.end();
});
CLIENT.get('/', function () {});
});