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
Upgrading caused promises to lose domain propagation #521
Comments
Domains are deprecated in io.js and support has been removed in 3.0. Not sure why you would use domains and promises at the same time though, promises make domains unnecessary. |
I am also concerned about this. I use domains pretty heavily in my app, in conjunction with promises. I use domains for request-specific data, like session:
I am unsure as to how I would accomplish the same thing without domains. I suppose it's possible to accomplish a similar effect with Promise.bind(), but then I can't use bind for it's intended purpose. Is there something I'm missing? |
You can use continuation-local-storage to achieve the same thing. |
I actually was using cls originally, but it was a huge pain because everything had to be shimmed. Most of the libraries I use currently support domains without me having to do anything. Asking a library author to support [Built In Library] seems pretty reasonable. I think it's much less likely that continuation-local-storage or whatever alternatives there may be will ever have the same support. Io.js deprecating domains to get rid of the sketchy error handling seems like throwing the baby out with the bath water. An "official" api for context-specific variables is a very useful thing. From the io.js docs on domains:
It's obviously up to you @petkaantonov, but maybe it would be ok to keep domain support until the replacement API is released? |
@dillonkrug domains themselves are a hack that require shimming everything, the reason why it even worked with bluebird promises in the first place because I added hacky code for them. But they won't work with native promises at all for example, because they cannot be shimmed. So yes, node shims its standard libraries by default, and 3rd party modules mostly rely on those, so this probably isn't as visible to you - but it's a shimming hack alright. |
Fixed in 2.9.23. I will also retain domain feature in 3.0 - it turns out non-usage can be optimized completely. |
That release (2.9.23) is backwards incompatible with (at least) node v0.10.26, presumably on behalf of this change – do you think you could cater to both iojs and node, and/or bump the major version and unrelease 2.9.23?
(I haven't tried 2.9.22 yet, but 2.9.21 still works just fine, so we can pin our dependencies to evade the problem temporarily at our end.) |
@johan This seems actually just a bug I didn't consider (multiple copies of bluebird being loaded). Are you loading multiple copies? |
Confirmed; my |
Should be fixed in 2.9.24 |
Thanks! Verified working. |
The bug seems to regress back in 2.10.2. Our domain code works well under 2.9.30, but finds corrupted domains with 2.10.2. |
We recently updated from version 2.3.4 to 2.9.12 and in doing so it broke domain propagation.
So within this code, our http handler accesses process.domain, within the first promise process.domain is defined and working correctly. But after the
.then()
process.domain no longer exists.The only fix we could find was downgrading our installation to 2.8.2 because we needed the changes from there. I'm not sure which version broke it, but it was something between 2.8.2 and 2.9.12. Just thought I should let you all know, let me know if that wasn't clear or if you have any other questions.
The text was updated successfully, but these errors were encountered: