Skip to content
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

Merged
merged 2 commits into from
Sep 28, 2024
Merged

9303 test upgrading send-anywhere #9719

merged 2 commits into from
Sep 28, 2024

Conversation

turadg
Copy link
Member

@turadg turadg commented Jul 16, 2024

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

Copy link

cloudflare-workers-and-pages bot commented Jul 16, 2024

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: b9c469b
Status: ✅  Deploy successful!
Preview URL: https://4b529a9e.agoric-sdk.pages.dev
Branch Preview URL: https://9303-orchestrate-upgrade.agoric-sdk.pages.dev

View logs

@turadg turadg force-pushed the 9303-orchestrate-upgrade branch from 7e2a619 to 4c8a8ee Compare July 16, 2024 22:41
mergify bot added a commit that referenced this pull request Jul 16, 2024
_incidental_

## Description
Miscellaneous cleanups while starting #9719 for #9303.

See each commit title for changes

### Security Considerations
none

### Scaling Considerations
none

### Documentation Considerations
none

### Testing Considerations
CI

### Upgrade Considerations
not yet deployed
@turadg turadg force-pushed the 9303-orchestrate-upgrade branch from 4c8a8ee to 77018cf Compare July 23, 2024 14:17
Copy link

codecov bot commented Jul 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 56.01%. Comparing base (c7eca9b) to head (77018cf).

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     

see 6 files with indirect coverage changes

mergify bot added a commit that referenced this pull request Jul 26, 2024
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
@turadg turadg force-pushed the 9303-orchestrate-upgrade branch from 77018cf to a3b92fa Compare July 29, 2024 20:26
@turadg
Copy link
Member Author

turadg commented Jul 29, 2024

Experimenting with these merged:

Comment on lines +71 to +73
// BUG: this never resolves
return new Promise(() => {});
Copy link
Member

@mhofman mhofman Sep 17, 2024

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)

@turadg turadg force-pushed the 9303-orchestrate-upgrade branch from b7c91ae to e7fb71a Compare September 27, 2024 17:27
@turadg turadg marked this pull request as ready for review September 27, 2024 17:29
@turadg turadg requested a review from a team as a code owner September 27, 2024 17:29
@turadg turadg changed the title 9303 orchestrate upgrade 9303 test upgrading send-anywhere Sep 27, 2024
@turadg turadg force-pushed the 9303-orchestrate-upgrade branch from e7fb71a to d9a7e47 Compare September 27, 2024 20:05
Copy link
Member

@mhofman mhofman left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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

Comment on lines 24 to 31
* 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.
*/
Copy link
Member

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.

@turadg turadg added the automerge:rebase Automatically rebase updates, then merge label Sep 27, 2024
@turadg turadg force-pushed the 9303-orchestrate-upgrade branch from 2d48e14 to 97f1db2 Compare September 27, 2024 23:37
@turadg turadg force-pushed the 9303-orchestrate-upgrade branch from 97f1db2 to b9c469b Compare September 28, 2024 00:06
@mergify mergify bot merged commit e3b41dc into master Sep 28, 2024
80 checks passed
@mergify mergify bot deleted the 9303-orchestrate-upgrade branch September 28, 2024 00:40
mergify bot added a commit that referenced this pull request Oct 4, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge:rebase Automatically rebase updates, then merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants