feat(asyncFlow): E support
#9322
Conversation
Deploying agoric-sdk with
|
| 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 |
erights
added
the
asyncFlow
erights
force-pushed
the
markm-asyncFlow-E
branch
2 times, most recently
from
e8e56d9
to
7575a6c
Compare
erights
force-pushed
the
markm-async-flow
branch
2 times, most recently
from
596304e
to
4cb7ed6
Compare
erights
force-pushed
the
markm-zonify-vowTools
branch
from
f40cf7e
to
a0198f0
Compare
erights
force-pushed
the
markm-zonify-vowTools
branch
from
a0198f0
to
055c780
Compare
erights
force-pushed
the
markm-asyncFlow-E
branch
from
174eb1c
to
97b8266
Compare
erights
force-pushed
the
markm-asyncFlow-E
branch
2 times, most recently
from
e9420ab
to
98c12fb
Compare
There was a problem hiding this comment.
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)
| const hostPromise = optVerb | ||
| ? E(hostTarget)[optVerb](...hostArgs) | ||
| : E(hostTarget)(...hostArgs); | ||
| resolver.resolve(hostPromise); // TODO does this always work? |
There was a problem hiding this comment.
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.
| : E(hostTarget)(...hostArgs); | ||
| resolver.resolve(hostPromise); // TODO does this always work? | ||
| } catch (hostProblem) { | ||
| throw Fail`internal: eventual send synchrously failed ${hostProblem}`; |
There was a problem hiding this comment.
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.
| // TODO FIX BUG this is not quite right. When guestResultP is returned | ||
| // as the resolution of guestResultP, it create a visious cycle error. | ||
| const hostResultKit = makeVowKit(); | ||
| bijection.init(guestReturnedP, hostResultKit.vow); |
There was a problem hiding this comment.
Can you clarify how this cycle could actually happen?
| const hostResultKit = makeVowKit(); | ||
| bijection.init(guestReturnedP, hostResultKit.vow); |
There was a problem hiding this comment.
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.
| } catch (problem) { | ||
| throw panic(problem); | ||
| } |
There was a problem hiding this comment.
Doesn't the caller of performSend already panic on exceptions?
| const promise = new HandledPromise((res, rej, _resPres) => { | ||
| resolve = res; | ||
| reject = rej; | ||
| }, guestHandler); |
There was a problem hiding this comment.
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.
| case 'throw': { | ||
| throw outcome.problem; | ||
| } |
There was a problem hiding this comment.
I don't think this can ever happen, can it?
| ? E(hostTarget)[optVerb](...hostArgs) | ||
| : E(hostTarget)(...hostArgs); |
There was a problem hiding this comment.
In the case of host vows, we should be using the V helper instead of E
There was a problem hiding this comment.
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).
Co-authored-by: Mathieu Hofman <86499+mhofman@users.noreply.github.com>
erights
force-pushed
the
markm-asyncFlow-E
branch
from
e495bc2
to
ac83c52
Compare
erights
force-pushed
the
markm-asyncFlow-E
branch
from
ac83c52
to
a461f24
Compare
erights
force-pushed
the
markm-asyncFlow-no-E
branch
from
b1796b5
to
7416d5d
Compare
closes: #XXXX refs: #9299 #9322 ## Description Prepare for #9322 by making any guest use of `E` until then cause an error. We expect that it might be a while before #9322 is ready for review. By merging this PR soon, we prevent any guest code or logs that would commit us to an incompat way of handling `E`. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations Should document that guests cannot invoke host vows or remotables with `E` until #9322 , which won't happen immediately. ### Testing Considerations - [x] need to test what kind of error state this goes into. Should be a panic, so that an upgrade can unblock guest execution that got stuck trying to `E`. ### Upgrade Considerations The point. By making such use of `E` an error now, we ensure that #9322 can proceed without causing any compat problem with committed durable state. Co-authored-by: Mathieu Hofman <86499+mhofman@users.noreply.github.com>
closes: #XXXX refs: #9322, #9299 #9443 ## Description PR #9322 is supposed to provide production quality support for asyncFlow guest functions to use `E`. It is being reviewed for that goal, and will not be merged until we think it meets that bar. However, we need to start integration testing of asyncFlow with orchestration, to spot mismatched assumptions we may have missed. For this purpose, we do not immediately need production quality `E` support. That is the purpose of this PR. It starts as a copy of the code from #9322 but need only be evaluated as adequate for these stopgap purposes before being merged. This PR does *NOT* claim to f-i-x #9299 , leaving that job to remain with #9322 Even though the requirements on this PR are so much lighter, reviewers should still look at the unresolved conversations on #9322 and determine if any of those need to first be solved even in this PR. ### Security Considerations When merging stopgap code to master, there is always the danger that it might be used as if it production code. We need to remember not to do so, instead waiting for #9322 to do the job for real. ### Scaling Considerations none ### Documentation Considerations just as this stopgap unblocks integration testing, it also likely unblocks documenting how to use asyncFlow, both in general and for orchestration. ### Testing Considerations As a stopgap, this PR does not need the rigorous testing that #9322 should have. ### Upgrade Considerations We need to not use this stopgap for production purposes.
refs: #9541, #9322, #9519 ## Description add `getVBankAssetInfo()` method on agoric chain object. DRAFT until - [x] how to add chain-specific methods to return type of `getChain()`? - [x] refactor uses of `makeResumableAgoricNamesHack` to use this ### Documentation Considerations change is visible via `orchestration-api.d.ts` cc @dtribble ### Security Considerations none? ### Scaling Considerations returns O(n) data from O(1) args ### Testing Considerations perhaps not independently tested ### Upgrade Considerations not yet deployed
|
Closing for now as we're reevaluating our approach for eventual-send support. |
Staged on #9443
closes: #9299
refs: #9097 #9336 #9519
Description
To support guest uses of
Eto do eventual sends,Not yet implemented
applyMethodto translate an eventual send on the guest wrapper into a corresponding eventual send to the host target, logging it as acheckSend, by analogy with acheckCall. Like acheckCallthat immediately returns a promise, it will be followed immediately by a correspondingdoReturnof the corresponding vow. UnlikecheckCall/doReturn, there is no possible callback interleaving between acheckSendand itsdoReturn. Later, when the target vow has settled, that will cause a correspondingdoFulfillordoReject. UnlikecheckCall, the target of acheckSendcan 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
Upgrade Considerations
Prior to #9443 and this PR, a guest use of
E(guestWrapper).foo()would, in a later turn, do a guest-sideguestWrapper.foo()causing acheckCall/doReturnto 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 causecheckSendto get logged with an immediatedoReturnof a promise that later settles with adoFulfillordoReject. With this change in the log, we expect we have durable logs we're willing to commit to.