Issue warnings when Express used in "unexpected" ways #5859
Replies: 2 comments 1 reply
-
We're already accounting for this in Express 5.0
I believe someone tried to make a PR for this at some point, but it's basically an impossible thing to ever correctly detect. If you have any thoughts along how we could implement this, that would be a greate conversation :) ! Thanks for your feedback, of course! We hate hard-to-debug issues as well, and this topic has come up a few times, but there has never really been any workable proposals put forward with out to actually tackle the issue, so what would help a lot is if you could put together some concrete proposals for how we can go about adding the guards, maybe even making PRs :) I know I draw a blank on these, which is why there are no guards (i.e. we don't have the guards not because we didn't think of them, but because we have yet to think of how to even create them). |
Beta Was this translation helpful? Give feedback.
-
Great, glad to hear! I will put it on my todo list and see if I can come up with a proposal, thanks! |
Beta Was this translation helpful? Give feedback.
-
Overall, I am very pleased with Express and have developed very successful API's with it. However, I decided to raise this issue, because over the last couple of months, I've run into 3 separate very hard to debug issues with different apps, which all shared the same common root causes in Express.
Basically in all of the cases it boiled down to user error, and was one of two things:
next()
twice in the same middleware due to a forgotten/omittedreturn
.res.end()
while there was more middleware expected to runIn each case, Express did not actually trigger an error, but the resulting behaviour of the app was very flaky and it took us a long time, literally hours, to pinpoint the problems which were in fact trivial to fix.
So my question is if it's possible to have Express "guard" against these kind of cases somehow and maybe depending on your configuration/settings, have Express trigger warnings if such unexpected behaviour is registered?
I realize it's probably a valid use case to have some middleware in the middle of the stack terminate the response, so it would be hard to write rules around that, but I don't think it's ever expected that the same
next
handler is called twice in the same middleware.Any thoughts on how we as developers can better guard against such issues?
Beta Was this translation helpful? Give feedback.
All reactions