Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
[BUG] "when" 3.7.7 package makes context get mixed up between concurrent HTTP requests #17
Link to strongloop/loopback#2871
Description of feature (or steps to reproduce if bug)
If using the
Link to sample repo to reproduce issue (if bug)
Sorry, I'm going to reproduce the issue more properly using
Actual result (if bug)
Additional information (Node.js version, LoopBack version, etc)
If I manage to include a solution to this issue in
I just found a workaround to this issue!!!
The trick is to "capture" both the
A good place to do this would be at the beginning of every user-defined middleware that uses the context. But this is not a trivial task. And it's not foolproof. In fact, some third-party middleware (i.e. neither one of yours, nor one from Strongloop) could lose context. And remember: once the context is lost, it's lost, no matter who wrote the middleware that lost it.
Another trick is to write
Same thing for
Also, I called
In general, if the package
It's good to know that a workaround exists, even in difficult cases like this! But I need to investigate this, because it's error-prone and needs a lot of care.
Maybe there is still some room for improvement?
@josieusa Awesome!! It's great to know that a workaround exists for some third-party module like
You must call
Only this way, if you call a method from a "cls-unaware" package (like
Don't forget that other middlewares/connectors that you didn't write yourself could still lose context, because of course they don't know about this workaround, and therefore they don't follow this rule. Issues happening in that code (which should be open source) should be easier to track, though.
Anyway, it's good to know that the loss of context won't happen anymore inside user code.
I am adding a mention of this problem to project's README - see #18.
@josieusa Thank you for investigating this problem and describing possible workarounds!
To be honest, they all look a bit hacky to me and I am little bit reluctant to include them in the official documentation. I think this issue is only emphasising the fact that continuation local storage in Node.js is simply not ready for prime time yet :(
Let's see what you come up with and discuss the details in the pull request. If there is a reasonable way how to make loopback-context more robust, then I think it makes sense to implement it, even if it does not get us to 100% reliability.
This has been discussed many times. I agree that it doesn't work out of the box. I didn't investigate enough the issues with connection pools yet, but I'll have to, sooner or later. Regarding the other issues with queues, I'm not sure that it all can't be solved (in an acceptable way, with some boilerplate) in user code; let's see how PR #19 goes.
Add bind:true option to getCurrentContext Workaround issue #17 with cujojs/when v3.7.7 due to the fact that it internally uses a mechanism of user-land queuing for async-related operations, and possibly issues with similar packages using queuing (mostly Promise libraries)