continuation-local-storage support for bluebird promises

Patch bluebird for continuation-local-storage support.

Current Status

Version 2.x of cls-bluebird is a complete re-write aiming to make it 100% reliable and robust. Features comprehensive test coverage (over 100,000 tests) which cover pretty much all conceivable cases.

Compatible with bluebird v2.x and v3.x. Tests cover both versions.

Please use with latest version of bluebird in either v2.x or v3.x branches. Older versions are not guaranteed to work.

Usage

clsBluebird( ns [, Promise] )

1var cls = require('continuation-local-storage');
2var ns = cls.createNamespace('myNamespace');
3
4var Promise = require('bluebird');
5var clsBluebird = require('cls-bluebird');
6
7clsBluebird( ns );
8// Promise is now patched to maintain CLS context

The above patches the "global" instance of bluebird. So anywhere else in the same app that calls require('bluebird') will get the patched version (assuming npm resolves to the same file).

Patching a particular instance of Bluebird

So as not to alter the "global" instance of bluebird, it's recommended to first create a independent instance of the Bluebird constructor before patching, and pass it to cls-bluebird.

This is a more robust approach.

1var Promise = require('bluebird').getNewLibraryCopy();
2var clsBluebird = require('cls-bluebird');
3
4clsBluebird( ns, Promise );

(see Promise.getNewLibraryCopy() docs on Bluebird website)

Nature of patching

Combining CLS and promises is a slightly tricky business. There are 3 different conventions one could use (see this issue for more detail).

cls-bluebird follows the convention of binding .then() callbacks to the context in which .then() is called.

1var promise;
2ns.run(function() {
3    ns.set('foo', 123);
4    promise = Promise.resolve();
5});
6
7ns.run(function() {
8    ns.set('foo', 456);
9    promise.then(print);
10});
11
12function print() {
13    console.log(ns.get('foo'));
14}
15
16// this outputs '456' (the value of `foo` at the time `.then()` was called)

Notes

Coroutines

The patch ensures that when execution in a coroutine continues after a yield statement, it always does so in the CLS context in which the coroutine started running.

1var fn = Promise.coroutine(function* () {
2    console.log('Context 1:', ns.get('foo'));
3    yield Promise.resolve();
4    console.log('Context 2:', ns.get('foo'));
5});
6
7ns.run(function(ctx) {
8    ns.set('foo', 123);
9    fn();
10});

outputs:

Context 1: 123
Context 2: 123

This means:

1. If the yield-ed expression loses CLS context, the original CLS context will be restored after the yield.
2. Any code before the yield which changes CLS context will only be effective until the next yield.

Global error handlers

Promise.onPossiblyUnhandledRejection() and Promise.onUnhandledRejectionHandled() allow you to attach global handlers to intercept unhandled rejections.

The CLS context in which callbacks are called is unknown. It's probably unwise to rely on the CLS context in the callback being that when the rejection occurred - use .catch() on the end of the promise chain that's created within namespace.run() instead.

Progression

Bluebird v2.x contains a deprecated API for handling progression (.progressed()) etc. These methods are patched and should work fine but they're not covered by the tests.

Tests

The tests cover every possible combination of input promises and callbacks that the Bluebird API allows. There's around 100,000 tests in total and the aim is to ensure cls-bluebird is as robust and reliable as possible.

Use npm test to run the tests. Use npm run cover to check coverage.

For more info on test tests, see tests/README.md

Changelog

See changelog.md

Issues/bugs

If you discover a bug, please raise an issue on Github. https://github.com/TimBeyer/cls-bluebird/issues

We are very keen to ensure cls-bluebird is completely bug-free and any bugs discovered will be fixed as soon as possible.

Contribution

Pull requests are very welcome. Please:

• ensure all tests pass before submitting PR
• add an entry to changelog
• add tests for new features
• document new functionality/API additions in README