Rejecting with a promise is not fully tested about promises-tests HOT 7 OPEN

I don't understand the state === "done" check enough to comment, really.

from promises-tests.

@ziriax It will probably be hard for us to comment, since we don't understand your code nearly as well as you do. If you could provide some sort of minimal test case that shows a potential problem, such as a particular test not matching a part of the Promises/A+ spec, that'd be extremely helpful.

from promises-tests.

Sorry for not making my question clear enough. I don't understand my own code that much either ;-) I tweaked it until all the specs passed, some of them were really hard to get right.

Let me try to explain my question in detail, with an example.

Consider the following code:

var def1 = deferred();
var prom1 = def1.promise;

var def2 = deferred();
var prom2 = def2.promise;

prom1.then(function (x) {
    console.log("done:" + x);
}, function (x) {
    console.log("fail:" + x);
});

def1.reject(prom2);
def2.resolve("foo");

What should be the correct output?

If I keep my promise implementation as initially pasted, I get the output:

fail:[object Object]

So prom1 is rejected with prom2 as-is, not doing any further resolution.

However, if I modify my transit method, removing the state === "done" check, I get the output

done: foo

In this case prom1 is rejected with prom2, but prom1 adopts the state of prom2, so eventually gets fulfilled...

Only one of the two behaviors can be correct, but I don't know which one.

So this means that I have two different implementations, both of them passing all the tests, but with different behavior.

The test suite doesn't seem to dictate the correct behavior, or at least not in the context of my own simple promise implementation.

What confused me in the A+ spec was

2.3.3.3.2: If/when rejectPromise is called with a reason r, reject promise with r.

It's not clear to me what to do when the reason r is another promise?

Thanks a lot,
Peter Verswyvelen

from promises-tests.

So this means that I have two different implementations, both of them passing all the tests, but with different behavior.

That means you found a bug in the test coverage; nice!

It's not clear to me what to do when the reason r is another promise?

You should follow the spec, and reject promise with r.

from promises-tests.

It's not clear to me what to do when the reason r is another promise?

Reject is verbatim. IOW, you shouldn't attempt to resolve r, but rather use r as the reason verbatim, even if r is a promise.

from promises-tests.

jinx again! :)

from promises-tests.

Nice catch!

from promises-tests.