-
-
Notifications
You must be signed in to change notification settings - Fork 103
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
Handle promises in middleware (catch rejections) #32
Handle promises in middleware (catch rejections) #32
Conversation
* Add lots of `return` calls for proxying the function returns back to the previous middleware stack function * Catch promise errors and pass to `next`
1892107
to
dd8c57f
Compare
@dougwilson I brought down the scope as discussed, and removed the "upstream" handling. This should be a separate module, |
I also tried this and was planning to make a pull request after my other two (#25 and #26) were merged. You can find that code here and the specific commit here if you want to compare. I can't remember all my conclusions (it was so long ago) but I do remember the problem of deciding when to call |
When I was developing the error catching feature, I ran into this concern. Is this also a concern in your implementation? I'd be very excited to see this merged, I've been using my implementation If you want some extra tests from when I did this see this compare. |
@calebmer No, it's not. I mentioned a few times in your previous PR not to mix the concerns, since they weren't related, so I've not included it here. I was looking at the compare, but it looks like most of the changes are related to Aside from that, I think there's a flaw (just briefly reading through) in the logic of your Anyway, yeah, run into the same concerns too. I did this same change a year ago with the same conclusion too, IIRC. I think proper upstream handling should instead be a part of a separate router implementation (probably |
Yeah for the reasons you stated I did abandon the idea as well, however error catching is still crucial. One note though, they I built the system there is one promise per request. My goal was more focused on catching errors then providing a good upstreaming system. Not much thought was put into it so I did not consider some of those ideas. |
Any progress? @calebmer, @blakeembrey |
why is this pending so long? |
To follow up on this, can we drop the bluebird dep and then get this merged? |
Hm, I am not clear on the differences. Let me dig in a bit more. |
I believe on my work machine I have one of those two staged after resolving conflicts. I won't be back to work until later this week, but I would think that would be the one. (I believe that is the machine I was working on the 2.0 branch on). |
Ok, I think the other one is a smaller change, and should solve the problem at hand. So that seems the most "promising" ;) to me |
The plan is to release an 2.0 alpha 1 with the promise changes so we have time to play with them as well, so can change our minds after the fact too. |
Ok, so I am wondering what all these returns are for here? Is this supposed to be used to |
Just a heads up, but I think promise handling (basically the code from this PR in To @wesleytodd's point, yes, the returns were to ensure compatibility with upstream handling (you could router.all(function (req, res, next) {
const startTime = Date.now() // Actually use `process.hrtime` in reality.
const result = await next()
res.setHeader('X-Timer', Date.now() - startTime)
return result
}) |
So basically, #47 looks solid today. If someone wants to look into the advanced functionality in the future, that's cool, but I probably won't be myself since keeping backward compatibility here is difficult to do and "downstream/upstream" behaviour is probably better as a new router. |
Yea, #47 is ultimately what is going to end up getting merged into 2.0 as an alpha, at which point I will rebase this PR on top of that so we can evaluate this prior to 2.0 finalization. |
I need more time to focus on the problem and backward compatibility and what it all should mean. This is just some code and tests that I wrote in a few hours, but got stuck with upstream propagation of errors because the models conflict. Here's a couple of conclusions from the little test:
If someone else has tried something similar, please share your own conclusions and whether I should keep moving forward with trying to support upstream propagation of promise errors (currently I have upstream propagation of resolved promises working fine).
Example:
Full support will also restrict the node version, I believe, to
>= 0.12
, unless we want to include a polyfill in the library.Edit: So the piece I'm stuck most on and trying to resolve the best way to support is any legacy code that does not return (aka breaks the promise chain).
Edit 2: Probably best to drop all this extra attempt at handling upstream and move it to a separate router module. I'm having trouble reconciling how to support both modes at once, probably not (easily) possible.