Unwrapping resolved promises don't happen asynchronously

[msiconolfi]

Sorry if this a more appropriate question for StackOverflow, thought I would ask here first.

Not sure if this was mentioned before, but I was reading @getify You Don't Know JS - Async & Performance and came across the following example which seems to behave differently using bluebird than using the author's native-promise-only promise library.

The following code snippet is a node.js program that has previously installed the following:
npm install --save-dev native-promise-only bluebird

// file: p03-scheduling-quirks.js
var promiseImpls = [
    'bluebird',
    'native-promise-only'
];

promiseImpls.forEach(function(promiseImpl) {

    var Promise = require(promiseImpl);
    var p3 = new Promise( function(resolve, reject){
        resolve( 'B');
    } );

    var p1 = new Promise( function(resolve, reject){
        resolve( p3 );
    } );

    var p2 = new Promise( function(resolve, reject){
        resolve( 'A' );
    } );

    p1.then( function(v) {
        console.log('Using ' + promiseImpl);
        console.log( v );
    } );

    p2.then( function(v) {
        console.log('Using ' + promiseImpl);
        console.log( v );
    } );
});

Output after running:

± node p03-scheduling-quirks.js
Using native-promise-only
A
Using native-promise-only
B
Using bluebird
B
Using bluebird
A

@getify states that according to spec (still looking for the source):

The specified behavior is to unwrap p3 into p1, but asynchronously, so p1's callback(s) are behind p2's callback(s) in the asynchronous Job queue.

I've also ran the code snippet in a ES6 fiddle to see what happens and get the same behavior as using native-promise-only.

Question
I understand that this is quirky behavior and in general one should not assume anything about the order of callbacks, but can anyone comment on why bluebird promises behave this way? Is it for performance?

[benjamingr]

Someone pinged getify here again, everyone run.

(Joke is a reference to an older discussion we've had about unrelated stuff - in practice we're actually all cool - I think I'm even mentioned in that chapter IIRC).

[benjamingr]

The spec does not mandate the order here. You can check different platforms with native promises (like other JS engines) and get varying results.

NPO and bluebird probably just use different schedulers and both results are valid.

Resolution is always synchronous (promise constructor has to run synchronously) - what's "asynchronous" is the onFulfilled callbacks executing.

[benjamingr]

I'm starting to wonder if this is correct - as EnqueueJob is called on resolution itself in the spec.

[benjamingr]

So Promise.resolve(x) calls NewPromiseCapability which does GetCapabilitiesExecutor which assumes resolve/reject arguments.but those are not passed to it.

I'm missing something. @domenic care to tell me what I'm missing in the spec?

[petkaantonov]

They are called asynchronously, just in different order. It was impossible to have same order as native promises without suffering from the memory leak native promsies suffer from (promises-aplus/promises-spec#183, promises-aplus/promises-spec#179).

[msiconolfi]

Thanks for clarifying @petkaantonov