-
Notifications
You must be signed in to change notification settings - Fork 212
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
9303 test upgrading send-anywhere #9719
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
7e2a619
to
4c8a8ee
Compare
4c8a8ee
to
77018cf
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #9719 +/- ##
==========================================
- Coverage 56.37% 56.01% -0.37%
==========================================
Files 667 666 -1
Lines 207560 207135 -425
Branches 343 171 -172
==========================================
- Hits 117022 116017 -1005
- Misses 90420 90999 +579
- Partials 118 119 +1 |
refs: #9303 ## Description Tests restarting an orchestration flow while an IBC message is pending response. #9303 will be closed when this and #9719 have landed. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations none ### Testing Considerations per se ### Upgrade Considerations helps, no change
77018cf
to
a3b92fa
Compare
Experimenting with these merged: |
// BUG: this never resolves | ||
return new Promise(() => {}); |
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 we add a comment of what exactly will hang in the test? I tracked down that chainHub
uses agoricNames
with retriable
, so I assume something in the test will trigger usage of chainHub and its retriable vow to not be resolved before upgrade, but I lost track of how exactly that happens.
Also we should provide a little more details as to why this is a valid test (and equivalent to the previous one, which had the pending promise explicitly created in the vat being upgraded). Here the buggy agoricNames
is external to the vat being upgraded, which means upgrading the vat will not reject the result promise for the E(agoricNames).lookup()
call. However that call is simply awaited in a retriable
async function, which means there is a local promise created and watched (the result of the async function), which is pending at vat upgrade, and which will be rejected on upgrade.
Interestingly, the lookup result promise will remain pending forever, causing a "leak" of the promise subscription (in the real world until the decider of the promise upgrades) even though the subscriber is actually no longer interested in the promise. This is a liveslots "limitation" that I created an issue about (#10101)
509278f
to
11879f7
Compare
b7c91ae
to
e7fb71a
Compare
e7fb71a
to
d9a7e47
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.
LGTM, assuming some details are added on how the test works exactly. As I originally mentioned in https://github.com/Agoric/agoric-sdk/pull/9719/files#r1763727074, it took me some time to understand what was going on in this test.
|
||
/** | ||
* This test core-evals a buggy installation of the sendAnywhere contract by | ||
* giving it a faulty `agoricNames` service with a lookup() function returns a |
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.
* giving it a faulty `agoricNames` service with a lookup() function returns a | |
* giving it a faulty `agoricNames` service with a lookup() function which returns a |
* Because the send-anywhere flow requires a lookup(), it waits forever. This | ||
* gives us a point at which we can upgrade the vat with a working agoricNames | ||
* and see that the flow continues from that point. | ||
*/ |
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 we clarify that the lookup
call is not made directly in a flow, but instead from a host API which uses the retriable
helper. As such it tests both the idempotent retry mechanism of retriable
on upgrades, and the ability to resume an async-flow for which a host vow settles after an upgrade.
2d48e14
to
97f1db2
Compare
97f1db2
to
b9c469b
Compare
closes: #9830 refs: #9722 #9719 ## Description #9719 originally failed on upgrade replay for an endowment. It revealed a bug introduced to async-flow when adding support for endowments. Because of the so-called "unwrapping" of some guests, there can be two guests corresponding to one host, with the host of course only mapping back to one of them -- the outer one. This makes `bijection.js` more complicated and irregular than an actual bijection. `equate(g, h)` had a test for early return, if the `g` and `h` were already "equated", i.e., were corresponding guest and host. But the equate test was written before the elaboration of bijection. In fact, it should only test whether this guest `g` maps to the host `h`, irrespective of whether `h` maps back to this `g`. Additional testing revealed that the unwrapped function was also not passable, and would fail to be passed back as an argument. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations This change potentially makes the diagnostic error when misusing async-flow slightly less precise. ### Testing Considerations Introduces equate checks in the endowments test exercising the bijection. For endowments with are further "unwrapped", we test both the original guest (which was previously failing) and the unwrapped one (which also was, but for a different reason). Since #9719 landed with a failing test, this PR also sets that test as passing, effectively working as an integration test of functions as endowments. ### Upgrade Considerations Can be deployed as a new version of the async-flow NPM package.
refs: #9303
Description
This adds a test for upgrading send-anywhere. It doesn't yet pass without these in-flight PRs,
We've agreed to land this without those to reduce work-in-flight.
Security Considerations
none
Scaling Considerations
none
Documentation Considerations
none
Testing Considerations
The failing test has a link to the issue to make it pass.
Upgrade Considerations
none