-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(async-flow)!: stopgap E
only for makeReplayMembraneForTesting
#10156
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that the reverted commit did more than simply enabling E support. I think we'll need to be more surgical. Let's discuss.
if (optVerb === undefined) { | ||
throw Panic`guest eventual call not yet supported: ${guestTarget}(${b(guestArgs)}) -> ${b(guestReturnedP)}`; | ||
} else { | ||
throw Panic`guest eventual send not yet supported: ${guestTarget}.${b(optVerb)}(${b(guestArgs)}) -> ${b(guestReturnedP)}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we just replace the guestHandler
with traps that do this? Possibly configured as an option when preparing the vow tools?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused by what you mean by "replace ... with traps". Are you talking about Proxy traps? Or eventual traps?
If eventual traps, that's exactly what the guestHandler already is.
f807dbb
to
ab33bad
Compare
enableEventualSend
option
ab33bad
to
b9398d0
Compare
b9398d0
to
3b75e30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little confused by the switching behavior of the test. Let's discuss
enableEventualSend
option3b75e30
to
fcc3dda
Compare
E
only for makeReplayMembraneForTest
E
only for makeReplayMembraneForTest
E
only for makeReplayMembraneForTesting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clean and targeted. Thanks for the updated tests
* @param {object} arg | ||
* @param {LogStore} arg.log | ||
* @param {Bijection} arg.bijection | ||
* @param {VowTools} arg.vowTools | ||
* @param {(vowish: Promise | Vow) => void} arg.watchWake | ||
* @param {(problem: Error) => never} arg.panic | ||
* @param {boolean} [arg.__eventualSendForTesting] CAVEAT: Only for async-flow tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish there was an easier way to "extend" options while being able to use JSDoc to document the additional option (the only one I'm aware of is multiple typedef
which is not clean)
closes: #9772
Description
To accomplish #9772, disable the stopgap eventual send support except when explicitly calling
makeReplayMembraneForTesting({..., __eventualSendForTesting: true })
. We do this surgically to allow the membrane tests to prevent regression concerning the stopgap eventual-send guest support, and provide coverage for when we implement proper, always-on eventual-send support.Security Considerations
The replay membrane used by asyncFlow cannot be overridden, so the stopgap
E
option is not available to users of asyncFlow, only to tests that are explicitly usingmakeReplayMembraneForTesting
.Scaling Considerations
n/a
Documentation Considerations
n/a
Testing Considerations
n/a
Upgrade Considerations
None, provided the version of async flow before this PR has not yet been deployed.