feat(async-flow): error on guest E use

[erights]

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

• 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.

[cloudflare-workers-and-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	7416d5d
Status:	✅  Deploy successful!
Preview URL:	https://12794b01.agoric-sdk.pages.dev
Branch Preview URL:	https://markm-asyncflow-no-e.agoric-sdk.pages.dev

View logs

[mhofman]

I'll let @michaelfig review the HandledPromise logic in the makeGuest* functions, my brain always hurt thinking of the handler plumbing.

• 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.

I just had a pesky thought about the following:

const payment= E(purse).withdraw(amount);
foo.receive(payment); // note not using `E` here. `foo` is a guest wrapper of a host local exo

at the time receive is called, payment is a basic HandledPromise unknown to the membrane because the promise handler is always called in a future turn (but always same crank). I honestly do now know how to solve this except providing our own E with our own HandledPromise implementation, or somehow enforce that the payment promise argument becomes know by the next turn, but I'm really warry of going down turn counting routes.

[erights]

I'll let @michaelfig review the HandledPromise logic in the makeGuest* functions, my brain always hurt thinking of the handler plumbing.

• 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.

I just had a pesky thought about the following:

const payment= E(purse).withdraw(amount);
foo.receive(payment); // note not using `E` here. `foo` is a guest wrapper of a host local exo

at the time receive is called, payment is a basic HandledPromise unknown to the membrane because the promise handler is always called in a future turn (but always same crank). I honestly do now know how to solve this except providing our own E with our own HandledPromise implementation, or somehow enforce that the payment promise argument becomes know by the next turn, but I'm really warry of going down turn counting routes.

I don't understand the problem. You didn't say what purse is, so let's break it down into two cases

• purse is a guest thing, so the E(purse).withdraw(amount) is completely within the guest side. In this case, payment is a guest-created guest promise. Then, on the next line when payment is used as an argument in a host call, it fails for reasons already tested before this PR: The guest cannot pass guest-created guest promises as arguments in host calls.
• purse, like foo, is guest wrapper of a host remotable. In that case it fails on this line because of exactly the use of E prohibited by this PR.

My guest is you mean the first. But either way, AFAICT, it should work. What am I missing?

[erights]

I asked

What am I missing?

offline @mhofman explained

basically the problem is that even if purse is a guest wrapper, by the time we see payment used as an argument, the purse "pending / presence handler" has not yet been invoked (delayed by a turn always by eventual send / HandledPromise), so we don't know that payment is a handled promise derived from the membrane.

to which I responded

Right. We’d need to register it during the eventual send itself, which requires some kind of handler to run synchronously, which conflicts with our protection against reentrancy.

Just to separate issues, this threatens #9322 , but not #9443 , right? The latter (#9443) can still proceed?

[erights]

agoric-sdk/packages/async-flow/test/bad-host.test.js

Lines 64 to 67 in ceec1d5

	t.throws(() => badGuest.badMethod(guestCreatedPromise), {
	message:
	'In a Failed state: see getFailures() or getOptFatalProblem() for more information',
	});

verifies that passing a guest-created promise as argument of a host call is a panic. With that settled, this PR is Ready for re-review

[mhofman]

Conditional approval assuming the suggested test change is not controversial. I would also still feel more comfortable if @michaelfig could double check that we're setting up eventual-send handlers the right way on guest objects.