Sequence's order of execution may be wrong in some cases

[SkidX]

Sequence's order of execution may be wrong in some cases

[getify]

I'm not sure what you mean by "wrong" order? You call done() which tells the sequence that on the next available tick of JS execution, it's OK to move on. But then you do some more work by doing a setTimeout(). Are you expecting the setTimeout() itself to somehow delay the sequence from moving on?

[SkidX]

The setTimeout is there just to emulate a slower async execution (in my case was an ajax call).
What I would expect is for each sequence step to be allowed to run only if the "done()" inside the previous sequence step is called, not by the call of "any" done(). So in my example I would expect the third item (printing 3) to wait for the done() call in the second item (printing 2). I would prefer that each done callback passed to each sequence step would be strictly bound to trigger that specific step conclusion, not as a global sequence trigger. In this way the expected order (1, 2, 3, 4) would be always respected, as it always happens if you remove the accidental second call to done() in the first step.

[getify]

The done is bound to only that step, and to only be executed once (subsequent calls of the same done are ignored). In your code, the first call to done marks the sequence as ok to advance to the second step, sets up the 10 timeout, advances to the next step, sets up the 500 timeout, then prints 1.1 from the first timeout, then prints 2 from the second timeout, then calls the second step's done, which advances the sequence to step 3, and so on. This is all reflected by the output as you show.

This is all entirely by design. I'm not sure where your confusion might be, but your code above does exactly what it should do.

Perhaps you're missing that step 1 tries to call its done both before and after the 10 timeout? Perhaps your confusion is that setTimeout somehow hooks into the inner workings of the sequence to control it... but setTimeout is a JS thing entirely independent of the sequence.

Can you try to clarify why you think the done is not step-bound, because it absolutely is?

[legodude17]

I think they were confused because apparently the output was

1
1.1
3
4
2

instead of

1
1.1
2
3
4

[SkidX]

Nope, this is not what is happening, both 3 and 4 are printed before 2 in my example. I added some messages so it is clear who is triggering what:

asq()
    .then(function(done) {
        console.log(1);
        done('first step trigger');
        setTimeout(function() {
            // second call by mistake
            done('first step trigger (too)');
        }, 10);
    })
    .then(function(done, msg) {
        setTimeout(function() {
            console.log(2, 'triggered by ', msg);
            done('second step trigger');
        }, 500);
    })
    .then(function(done, msg) {
        console.log(3, 'triggered by ', msg);
        done('third step trigger');
    })
    .then(function(done, msg) {
        console.log(4, 'triggered by ', msg);
        done();
    })
;

And this is the output I'm getting:

1
3 "triggered by " "first step trigger (too)"
4 "triggered by " "third step trigger"
2 "triggered by " "first step trigger"

As you can see, both 3 and 2 are triggered by done calls inside the first step, so the done function is not actually bound to a single step and the subsequent call is not ignored.
The 3 is coming before the 2 because it is triggered by the first step before the 2 is finished.

[SkidX]

This is a pen reproducing what I said (please open the console to see the output)
http://codepen.io/SkidX/pen/XNqQZr

[legodude17]

@SkidX, I was saying that you got 3 and 4 before 2 instead of the expected one. I saw the pen, and that does look like a bug. If you comment out the second done() it works as expected.

[SkidX]

@legodude17, sorry, when I said "nope..." I was answering to @getify but I forgot to mention him.
Yes, as you said removing the second done() it works exactly as expected, but this means that subsequent calls to the same done function are not actually ignored.

[getify]

Sorry I missed the problem in ordering of 3 and 4 in the OP. Shouldn't have been trying to triage a bug while on a mobile device. :)

Verified bug. I had tests in the test suite that were supposed to catch this, but didn't. :(

Fix incoming.

[SkidX]

Thanks a lot for the quick fix, I just tested it also in my real world scenario and it works perfectly.