Cloning promises between realms

[domenic]

First step in figuring out #5. The use case in question: postMessaging a promise from window A (where it was created) to window B.

Promises are tricky because they not only have internal state to encapsulate (see their internal slots), but also that internal state can be manipulated by their creator in window A.

For maps and sets, their internal state can also be manipulated, but once the clone happens, they are disconnected: window A and window B end up with completely different maps. Is this right for promises? There are a few reasons to think not:

• Promises represent an async operation; maps represent a mutable data structure. If you clone a map and get a snapshot, you still have a mutable data structure on the other side; its "essence" has been maintained. But if you clone a pending promise and it then stays pending forever (i.e. is snapshotted), then you no longer have something representing that async operation on the other side: its "essence" has been lost.
• Promises are inherently asynchronous, so it seems much more possible to maintain the link between the original and the clone.

Thus, I think the following would work:

1. Promise B gets initialized with the same [[PromiseState]] and [[PromiseResult]] as promise A. If [[PromiseState]] is "fulfilled" or "rejected", then there's nothing to do. (If [[PromiseState]] is undefined, then someone tried to clone the promise before it was initialized, and we should throw.)

2. The implementation internally adds something like:

   promiseA.then(v => resolvePromiseBWith(v), r => rejectPromiseBWith(r))

   As long as the implementation uses the original value of Promise.prototype.then, this would be unobservable in window A, which is good.

3. The resolvePromiseBWith and rejectPromiseBWith meta-functions would go through the public API in the same way as all of the promise spec currently does. More formally, in step 1 we would save the resolve and reject functions passed to us by the constructor, and resolvePromiseBWith(v) would essentially be something like "post a message to window B to call the resolve function it saved with value v"

4. If v or r are not structured-clonable, instead the implementation would post a message to window B to call the reject function it saved with an informative error. I guess we'd need to take this into account during step 1 as well.

Still to think about: how to match up constructors across realms? E.g. if someone subclasses Promise to CancelablePromise, how do we ensure that a clone of a cancelable promise from window A becomes a cancelable promise in window B? Should it even be such a cancelable promise? This seems to be a larger issue related to much of the things this repo is generally concerned with. For a first pass, I'd be happy with just reconstituting as normal Promise instances, as long as it's future-compatible. (E.g. in the future subclasses could have a "make clone data" and "initialize with clone data" hook that gets called if they are present?)

[tabatkins]

You've skipped a step, or some explanation, where the resolve/rejectPromiseBWith() functions to structured cloning on the passed values; without that extra detail, much of this would be simplified by just creating a new promise on the far end resolved to the original promise.

Otherwise, I agree with the overall thrust, that making separate promises completely ruins the promise itself; might as well just make promises error when cloned instead, rather than doing a completely useless and broken clone.

I also agree that starting from a basic Promise (losing any subclass features) is probably fine, with the option to upgrade in the future.

[domenic]

I kind of covered that in step 4, but only in an indirect way, I agree.

[tabatkins]

Yeah, if you intended Step 4 to implicitly handle that, then you can indeed just replace Steps 1-3 with "make a new promise on the far end, resolve it with the starting promise" and be done.

[domenic]

I don't understand how. You can only resolve with objects that are in your realm, and the entire purpose of steps 1-4 is to define how to get a (clone of) a promise for one realm to another.

[stefanpenner]

Let me know if I understood the cloning stuff correctly. If so, I have some concerns.

cloning promise that has not yet settled:

• if it settles to a result which is not structured-clonable result we should reject the cloned promise.
• if it settles to a structured-clonable result, all is well

but to defend against zalgo, cloning settled promises should have the exact same semantics.

I feel like the destination realm having to deal with the originating realm's mistakes is entirely non-actionable and potentially frustrating. Additionally, no feedback is provided to the originating realm.

[stefanpenner]

Also, is it even possible to structure clone an Error? Last time I tried I am pretty sure, it fell into the category of non cloneable.

If ^^ is correct, this would mean cloning fetch('user') would only work if the request was successful, otherwise you would get a structure clone error rejection, again rather un-actionable.

It may even cause an issue trying to push the structure clone error itself, Although I assume the internals could work around this.

If memories serves me, in a past project we ended up detecting error objects, during the clone phase, and replacing them with something sanitized but containing enough information to still be actionable. This was annoying, but enabled us to provide more actionable rejection reasons.

[tabatkins]

I don't understand how. You can only resolve with objects that are in your realm, and the entire purpose of steps 1-4 is to define how to get a (clone of) a promise for one realm to another.

Ah, gotcha, didn't realize that the Step 2 methods were the magical "transport values across realms" part.

but to defend against zalgo, cloning settled promises should have the exact same semantics.

That'll happen anyway, because we're just using standard resolution to transport the values across; it doesn't matter whether the promise is settled or not.

Also, is it even possible to structure clone an Error? Last time I tried I am pretty sure, it fell into the category of non cloneable.

If not, this is something fixable, probably along the lines you outline.

[stefanpenner]

If not, this is something fixable, probably along the lines you outline.

Sounds good.

I suspect one of the reasons is to prevent accidentally leaking information between realms. RE: stacktraces and stuff

That'll happen anyway, because we're just using standard resolution to transport the values across; it doesn't matter whether the promise is settled or not.

👍

[stefanpenner]

Subclassing and constructor identity gets confusing quick as well.

If each realm's constructors are unique, this will result in costly assimilation when using a foreign thenable.

[domenic]

If each realm's constructors are unique, this will result in costly assimilation when using a foreign thenable.

No more costly than normal. Steps 1-4 are basically a mini-assimilation algorithm in themselves, albeit one that works only for real promises.

[tabatkins]

Arbitrary thenables aren't structured-clonable. Real promises are, which means the assimilation has alreayd happened.

[stefanpenner]

@domenic ah, 1-4 would be doing the assimilation. so CancelablePromise.resolve(foreignCancelable) === foreignCancelable

[domenic]

There's no way to create or get a reference to foreignCancelable in this outline. Once you clone something, on the other side it becomes a Promise.

[stefanpenner]

@domenic so it would be this realms constructor correct?

Sorry my variable naming was poor

var payload = /* from message channel or something */
CancelablePromise.resolve(payload.cancelable) === payload.cancelable