2.2.2.2 fails when resolving synchronously outside of .then's event-loop-turn about promises-tests HOT 12 OPEN

The spec seems pretty clear that no matter what causes onFulfilled to trigger, any onFulfilled that is passed to then must never be called with a dirty stack.

from promises-tests.

That's the interpretation issue I was referring to. I think it would have been clearer if the spec said "after the event loop turn which triggered the call, be it then or resolve or reject"

from promises-tests.

The spec doesn't real with resolve or reject though. But it does deal with every onFulfilled passed to then.

from promises-tests.

True that...

from promises-tests.

Hi all,

This is also related to the interpretation of "after the event loop turn in which then is called, and with a fresh stack" as well so thought I'd pop it in here rather than new issue.

My promise implementation uses an internal trampoline queue (to cover the fresh stack/platform code aspect) & passes all current compliance tests but I'm concerned that I did not correctly implement the after event loop turn requirement...there doesn't seem to be any actual coverage of that requirement when dealing with adding a fulfilment handler to the same promise within a fulfillment handler to that promise.

I've modified a test from 2.2.4 to illustrate:

  describe("Clean-stack execution ordering tests (fulfillment case)", function () {
       ....
        specify("when one `onFulfilled` is added inside another `onFulfilled`", function (done) {
            var promise = resolved();
            var firstOnFulfilledFinished = false;

            promise.then(function () {
        var x
        ;
        process.nextTick(function () {
            x = 1;
        });
                promise.then(function () {
                    assert.strictEqual(firstOnFulfilledFinished, true);
            assert.strictEqual(x, 1);
                    done();
                });
                firstOnFulfilledFinished = true;
            });
        });

Am I correct in assuming that A+ implementation would pass this test: I.e. then called in a fulfillment handler is fulfilled in the next event loop turn?

from promises-tests.

@sterpe I believe this being left unspecified is intentional

from promises-tests.

@stefanpenner nope.

@sterpe that test is a bit tricky because it's interleaving two "async queues": process.nextTick and the promise queue. The test of firstOnFulfilledFinished is more useful than the test of x, because it says literally whether the promise queue has unwound. The test of x also tests that the nextTick queue has unwound. But that is not necessary for conformance because the stack will still be clean.

You can picture it this way:

promise queue: [], nextTick queue: []
promise queue: [<set x to undefined>], nextTick queue: [<set x to 1>]
promise queue: [<set x to undefined>, <assert x === 1>], nextTick queue: [<set x to 1>]

At this point a bunch of stuff has been enqueued, but no other code is ready to run, so our stack is empty. Now it's time to start dequeing stuff. Let's say that things have worked out so that the promise queue comes before the nextTick queue. Then we have:

run <set x to undefined>
promise queue: [<assert x === 1>], nextTick queue: [<set x to 1>]

stack is again empty.

run <assert x === 1> (it will fail)
promise queue: [], nextTick queue: [<set x to 1>]

stack is again empty

run <set x to 1>
promise queue: [], nextTick queue: []

done; no more queued event loop work items. Node can now exit; browser can now GC; etc.

So this shows how an implementation can be conforming but still fail the x === 1 test.

from promises-tests.

@stefanpenner nope.

I must be missing something because you followed this up with an explanation as to why this is left unspecified.

from promises-tests.

Well, I guess it depends on perspective. But this is not an unspecified loophole. This is a very well-specified issue.

from promises-tests.

@domenic ah ok. I then believe my wording was incorrect. unspecified -> untested

from promises-tests.

@domenic, thanks for the clarification. I suppose then there's an unnecessary resolution speed penalty that an implementation would have to take in this situation waiting for the next tick queue to unwind in order to pass the 'x' test.

from promises-tests.

Or rather potential performance impact since you are ceding the thread back between the on fulfillment handler resolution.

from promises-tests.