feat(asyncFlow): E support

[erights]

Staged on #9443
closes: #9299
refs: #9097 #9336 #9519

Description

To support guest uses of E to do eventual sends,

• we make guest remotable wrappers of host remotables into remote presences. This avoids any need to distinguish between local host remotables vs host remote presences.
• we make guest promise wrappers of host vows into pipelinable promises.

Not yet implemented

• Both have a handler that will implement applyMethod to translate an eventual send on the guest wrapper into a corresponding eventual send to the host target, logging it as a checkSend, by analogy with a checkCall. Like a checkCall that immediately returns a promise, it will be followed immediately by a corresponding doReturn of the corresponding vow. Unlike checkCall/doReturn, there is no possible callback interleaving between a checkSend and its doReturn. Later, when the target vow has settled, that will cause a corresponding doFulfill or doReject. Unlike checkCall, the target of a checkSend can be either a remotable or a promise.

Security Considerations

just more surface area and more tricky things that might be wrong.

Scaling Considerations

should not be significantly different than the existing support for checkCall.

Documentation Considerations

one less restriction that needs to be documented. Once this PR works, it should "just work" in the sense of merely removing a surprise.

Testing Considerations

• write tests

Upgrade Considerations

Prior to #9443 and this PR, a guest use of E(guestWrapper).foo() would, in a later turn, do a guest-side guestWrapper.foo() causing a checkCall/doReturn to get logged. This is not incorrect on its own terms. But we need not to commit to any such durable logs prior to this PR. With this PR, that same expression will immediately cause checkSend to get logged with an immediate doReturn of a promise that later settles with a doFulfill or doReject. With this change in the log, we expect we have durable logs we're willing to commit to.

• We need to decide how the asyncFlow mechanism should treat such errors.
  • Are they in model -- where the not-yet-implemented error gets thrown back at the guest function?
  • Or are they failures suspending the guest in a Failed state, so a later upgrade of the asyncFunc implementation would allow such failed guests to "resume" without requiring any change to the guest?

[cloudflare-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	290ded5
Status:	✅  Deploy successful!
Preview URL:	https://86dc382d.agoric-sdk.pages.dev
Branch Preview URL:	https://markm-asyncflow-e.agoric-sdk.pages.dev

View logs

[mhofman]

First pass, but I'm confused about the handling of the result vow. I understand we have the logic about interpreter nesting, but I think it would be simpler to include the result vow in the checkSend log entry, and have a synthetic doReturn with no result (and ignore the outcome completely on replay because it either succeeds or panics, a throw outcome should not happen for a checkSend)

[mhofman]

Yeah thinking about this, if hostTarget is a local object for which call returns a promise, we will fail during an upgrade. Unlike the checkCall case, we're not in a position to do any enforcment and fail unconditionally, unless we can somehow sniff the type of the hostTarget (if it has an eventual handler or not), and bypass the E call if it doesn't. If the hostTarget object does not return a promise, then the hostPromise will be fulfilled in the same crank, so it's safe.

[mhofman]

Since I didn't understand this right originally, let's add a comment: Since a well behaved eventual-send should not synchronously fail (it doesn't synchronously interact with the target), a synchronous throw does not represent a failure we should commit to, but instead is a panic.

[mhofman]

Can you clarify how this cycle could actually happen?

[mhofman]

I think if we're replaying we need to use the vow that was previously created for the send, no?

I also don't see how we're rewiring the guestReturnedP to the watched vow on replay.

[mhofman]

Doesn't the caller of performSend already panic on exceptions?

[mhofman]

FYI, makePromiseKit has some logic to sever references from the resolvers to the promise once resolved, but I think in this case all resolver users are well behaved and drop resolvers after usage, so we're good.

[mhofman]

I don't think this can ever happen, can it?

[mhofman]

In the case of host vows, we should be using the V helper instead of E

[mhofman]

After talking with @michaelfig we clarified that V is heap only, and does not queue sends durably. We need to structure the membrane handling of sends to vows such that they are only sent after the vow has settled. We can rely on the fact that the membrane has replayed (no need to durably store the pending sends, instead use the guest promise).