-
Notifications
You must be signed in to change notification settings - Fork 208
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
add support for Vows to smart-wallet #9308
Comments
how is that a problem? |
|
"handle" in what sense? "sufficient" in what sense? In what cases do we have vows as offer results? |
An offer handler that wants to survive upgrade will likely return a vow. This will happen automatically if implementing the offer handler as an async-flow. Maybe the problem is wider than the smart wallet, I am not sufficiently familiar with offers and zoe, but a vow returned by the offer handler would not represent the final result. For that, the vow needs to be watched to get the final result (I believe it's already possible for an offer handler to return a value before the offer is considered "done" or whatever the terminology is there) |
in particular, an async-flow that intends to result in invitationMakers needs support |
- smart wallet does not know the right thing to do when it receives a vow. happy paths may 'seem' ok since the offer result is Vow object. For failure paths, the smart wallet thinks a Vow object holding a Promise rejection is a successful offer result - until #9308, this makes bootstrap tests pass
- smart wallet does not know the right thing to do when it receives a vow. happy paths may 'seem' ok since the offer result is Vow object. For failure paths, the smart wallet thinks a Vow object holding a Promise rejection is a successful offer result - until #9308, this makes bootstrap tests pass
- smart wallet does not know the right thing to do when it receives a vow. happy paths may 'seem' ok since the offer result is Vow object. For failure paths, the smart wallet thinks a Vow object holding a Promise rejection is a successful offer result - until #9308, this makes bootstrap tests pass
* Make smart wallet use `when` to accept a Vow for the result of an offer NOTE: this enables upgrade of the contract, NOT upgrade of the smart-wallet refs: #9308 Co-authored-by: Dean Tribble <tribble@agoric.com>
* Make smart wallet use `when` to accept a Vow for the result of an offer NOTE: this enables upgrade of the contract, NOT upgrade of the smart-wallet refs: #9308 Co-authored-by: Dean Tribble <tribble@agoric.com>
* Make smart wallet use `when` to accept a Vow for the result of an offer NOTE: this enables upgrade of the contract, NOT upgrade of the smart-wallet refs: #9308 Co-authored-by: Dean Tribble <tribble@agoric.com>
* Make smart wallet use `when` to accept a Vow for the result of an offer NOTE: this enables upgrade of the contract, NOT upgrade of the smart-wallet refs: #9308 Co-authored-by: Dean Tribble <tribble@agoric.com>
* Make smart wallet use `when` to accept a Vow for the result of an offer NOTE: this enables upgrade of the contract, NOT upgrade of the smart-wallet refs: #9308 Co-authored-by: Dean Tribble <tribble@agoric.com>
closes: #XXXX refs: #9449 refs: #9308 ## Description Changes in this PR are related to #9449, primarily for `local-orchestration-account.js` and `cosmos-orchestration-account.js`, `service.js`, and `orchestrator.js`. Attenuated versions of these kit are what the caller of `...getChain('agoric' | 'cosmos').makeAccount()` receives. This PR also includes a change to `smart-wallet` so it understands how to unwrap **offerResult**s that are **Vow**s. This uses **heapVowTools** which means it does _**not**_ cover resumability in the scenario of `smart-wallet` upgrading - only the contracts that rely on it. Other small changes included changes: - `PromiseToVow` and `VowifyAll` type helpers, so we can still reference the idealized API spec in code that returns Vows - fix/refactor of `getTimeoutTimestampNS` logic that removes an unnecessary network call when the caller supplies values - lint rule: adds a warning when importing `heapVowE` in resumable code - resumable lint rule changes to **error**, now that all warnings are resolved ### Security Considerations N/A ### Scaling Considerations N/A ### Documentation Considerations N/A ### Testing Considerations Adds a test boot and unit tests for a rejected Delegate wallet offer, which is helpful for ensuring errors are properly propagated through the vow chain. Upgrade tests would be helpful here, but we haven't started on these yet. I don't think we need those to land this PR, although they are certainly critical before release. Would love to pair with someone on this and learn more about how we do that. ### Upgrade Considerations This PR contains a change to **smart-wallet**.
refs: #9308 ## Description - adds `asPromise` helper to `VowTools` for unwrapping `Vow|Promise`, ensuring proper handling of ephemeral promises - updates watch-utils to better handle values that are not storable durably, such as promises ### Testing Considerations This does not include tests that simulate an upgrade - only a heap zone is used in the included tests. See #9631 ### Upgrade Considerations This PR includes changes we'd like to be in the initial release of vows.
#9620 was revised to only include changes in |
refs: #9308 ## Description - adds `asPromise` helper to `VowTools` for unwrapping `Vow|Promise`, ensuring proper handling of ephemeral promises - updates watch-utils to better handle values that are not storable durably, such as promises ### Testing Considerations This does not include tests that simulate an upgrade - only a heap zone is used in the included tests. See #9631 ### Upgrade Considerations This PR includes changes we'd like to be in the initial release of vows.
refs: #9308 ## Description - adds `asPromise` helper to `VowTools` for unwrapping `Vow|Promise`, ensuring proper handling of ephemeral promises - updates watch-utils to better handle values that are not storable durably, such as promises ### Testing Considerations This does not include tests that simulate an upgrade - only a heap zone is used in the included tests. See #9631 ### Upgrade Considerations This PR includes changes we'd like to be in the initial release of vows.
refs: #9308 ## Description - adds `asPromise` helper to `VowTools` for unwrapping `Vow|Promise`, ensuring proper handling of ephemeral promises - updates watch-utils to better handle values that are not storable durably, such as promises ### Testing Considerations This does not include tests that simulate an upgrade - only a heap zone is used in the included tests. See #9631 ### Upgrade Considerations This PR includes changes we'd like to be in the initial release of vows.
- refs: #9308 Co-authored-by: Turadg Aleahmad <turadg@agoric.com>
- refs: #9308 Co-authored-by: Turadg Aleahmad <turadg@agoric.com>
- refs: #9308 Co-authored-by: Turadg Aleahmad <turadg@agoric.com>
- refs: #9308 Co-authored-by: Turadg Aleahmad <turadg@agoric.com>
- refs: #9308 Co-authored-by: Turadg Aleahmad <turadg@agoric.com>
What is the Problem Being Solved?
Currently when an OfferResult is a promise, smartWallet awaits it with
watchPromise
to record the offer result. If, as in the case of an async-flow from orchestration, the result is a Vow for a primitive or for invitationMakers, the current smart wallet implementation will discard the Vow rather than handling what it fulfills to.agoric-sdk/packages/smart-wallet/src/offerWatcher.js
Lines 30 to 40 in fbd8633
Description of the Design
We could use
watch
in VowTools in place of the current watchPromises.We might want to go further and use asyncFlow to refactor much of the smart wallet state handling.
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: