Expose the result promise (if there is one) to the handler

[michaelfig]

trafficstars

As @warner had concluded in Agoric/agoric-sdk (FIXME issue number?), it is sometimes important for the handler to be aware of the actual promise that will be returned to the user. For example, the handler may want to store that promise in a weakmap rather than the presence or internal promise it receives as the first argument.

For now, our shim appends an additional argument that is set to the resulting promise. To generalise this behaviour, we'd need to have this argument be undefined if there is no observable result promise.

Recording here for tracking.

[ljharb]

I'm not sure that should be a consideration - the identity of individual promises is not very reliable due to frequent use of await and Promise.resolve (and all the other combinators).

[michaelfig]

I'm not sure that should be a consideration - the identity of individual promises is not very reliable due to frequent use of await and Promise.resolve (and all the other combinators).

I understand this for most promises. When we are doing cross-address-space communications systems, we know which promise is being returned to the comm system, and beyond that, it is serialised (not resolved further).

It's important to know that promise's identity for things like GC, rather than some internal-to-the shim promise that doesn't need to be serialised.

[michaelfig]

I may have explained this badly. But the need for serialisation and still preventing premature GC of the promise is the motivator.

[ljharb]

I'm sure the confusion is on my end. Why would anyone want to use a promise's identity as a key? At least currently, that's unreliable and generally avoided due to the unreliable/inconsistent identity of promises, due to their common usage (it's also why subclassing Promises is generally avoided and considered an antipattern).

I'm also not sure how serialization comes into play.

[michaelfig]

Okay, after talking with @warner, I have a better way of explaining this: we want to be able to optimise the case where the promise that results from a handler invocation might be passed as an argument to another remote invocation, and to be able to encode it using the same identifier (which refers to a third-party for resolution, not the two parties involved in the message send and receive). This is only an optimisation, and does help reduce round-trips when we can avoid it.

For now, we can at least optimise some direct uses of that returnedP. The ideal would be to be able to notice all promises that are resolved to returnedP.

We are expecting (and make mention in the proposal) for there someday to be a way to subscribe to promise forwarding, which will allow the tracing of promises even through identity changes. When we have that feature, the returnedP argument to handler functions will be the basis that allows us to identify all the promises which are resolving to it.

Without that argument, our handlers would always have to create and return a new promise, just for use with forwarding detection. That may be preferable and more orthogonal, but we need the API first.

Until we have thought this through more carefully, I won't suggest that the additional returnedP argument be part of this proposal, just a feature of our shim.