You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@othiym23 can I ask your opinion on something? (this isn't an issue about CLS per se)
I've been having some problems using CLS, bluebird and co together, with CLS context sometimes getting lost. By way of trying to narrow down the problem, I've written a set of tests which run against various different bluebird CLS shims to see how they all behave in different circumstances.
(NB cls-bluebird2 is the beginnings of an attempt at a new cls-bluebird shim)
varPromise=require('bluebird');varcls=require('continuation-local-storage');varclsBluebird=require('cls-bluebird2');varassert=require('assert');varns=cls.createNamespace('test');clsBluebird(ns,Promise);// CASE 1varpromise;ns.run(function(){ns.set('test',123);promise=Promise.resolve().then(function(){assert(ns.get('test')==123);});});promise.then(function(){assert(ns.get('test')==123);});
Both assert statements pass in this case. I think that's the correct behaviour - the .then() outside of ns.run() should inherit CLS context from the previous promise in the chain.
But how about this:
// CASE 2varpromise;ns.run(function(){ns.set('test',123);promise=Promise.resolve();});promise.then(function(){assert(ns.get('test')==123);});
In this 2nd case, the assert statement fails.
Should it? My first thought was that it should execute in the context of the promise chain, in the same way as case 1. On the other hand, it's chaining onto a promise which is already resolved. So in what sense is it "following on from" that promise in the way that a node callback "follows on" immediately from the function that calls it?
What's your opinion?
More generally speaking, there are quite a lot of subtleties in reasoning the desired behaviour of CLS context passing with promises. async-listener's shim of native promises takes the view that it's all about following the chain of execution down the promise chain (and so both the above cases pass), whereas cls-bluebird executes code in a .then()in the context in which .then() was called (so both above cases fail).
Has anyone written down any kind of spec, or made a set of tests to define desired behaviour?
The text was updated successfully, but these errors were encountered:
@othiym23 can I ask your opinion on something? (this isn't an issue about CLS per se)
I've been having some problems using CLS, bluebird and co together, with CLS context sometimes getting lost. By way of trying to narrow down the problem, I've written a set of tests which run against various different bluebird CLS shims to see how they all behave in different circumstances.
Please see: https://www.github.com/overlookmotel/cls-bluebird-test
There's one weird case...
(NB cls-bluebird2 is the beginnings of an attempt at a new cls-bluebird shim)
Both assert statements pass in this case. I think that's the correct behaviour - the
.then()
outside ofns.run()
should inherit CLS context from the previous promise in the chain.But how about this:
In this 2nd case, the assert statement fails.
Should it? My first thought was that it should execute in the context of the promise chain, in the same way as case 1. On the other hand, it's chaining onto a promise which is already resolved. So in what sense is it "following on from" that promise in the way that a node callback "follows on" immediately from the function that calls it?
What's your opinion?
More generally speaking, there are quite a lot of subtleties in reasoning the desired behaviour of CLS context passing with promises. async-listener's shim of native promises takes the view that it's all about following the chain of execution down the promise chain (and so both the above cases pass), whereas cls-bluebird executes code in a
.then()
in the context in which.then()
was called (so both above cases fail).Has anyone written down any kind of spec, or made a set of tests to define desired behaviour?
The text was updated successfully, but these errors were encountered: