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

upgrade testing supports #9770

Merged
merged 18 commits into from
Jul 25, 2024
Merged

upgrade testing supports #9770

merged 18 commits into from
Jul 25, 2024

Conversation

turadg
Copy link
Member

@turadg turadg commented Jul 24, 2024

refs: #9303

Description

A bunch of refactors and testing utilities to support #9303.

It also adds a couple upgrade tests of orchestration contracts, but neither of them cover restarting orchestration flows so I'll leave #9755 for that.

Security Considerations

none

Scaling Considerations

none

Documentation Considerations

none

Testing Considerations

per se

Upgrade Considerations

Helps to test upgrades, should not affect any.

@turadg turadg requested review from dckc and 0xpatrickdev July 24, 2024 23:34
@turadg turadg force-pushed the 9303-upgrade-testing-supports branch from ef9165a to f44917f Compare July 25, 2024 00:10
Copy link

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

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: 816099a
Status: ✅  Deploy successful!
Preview URL: https://fd4e9c44.agoric-sdk.pages.dev
Branch Preview URL: https://9303-upgrade-testing-support.agoric-sdk.pages.dev

View logs

@Agoric Agoric deleted a comment from mergify bot Jul 25, 2024
Copy link

codecov bot commented Jul 25, 2024

Codecov Report

Attention: Patch coverage is 95.12195% with 6 lines in your changes missing coverage. Please review.

Project coverage is 56.40%. Comparing base (8a8fed3) to head (816099a).

Additional details and impacted files
Components Coverage Δ
SwingSet/kernel 73.36% <ø> (ø)
ERTP 92.45% <ø> (ø)
Orchestration 94.44% <25.00%> (+<0.01%) ⬆️
swing-store 95.95% <ø> (ø)
Files Coverage Δ
packages/boot/tools/drivers.ts 100.00% <100.00%> (ø)
packages/boot/tools/ibc/mocks.js 100.00% <100.00%> (ø)
packages/boot/tools/supports.ts 99.84% <100.00%> (-0.16%) ⬇️
packages/vats/src/core/lib-boot.js 85.06% <100.00%> (+0.13%) ⬆️
...rchestration/src/examples/sendAnywhere.contract.js 49.05% <0.00%> (ø)
packages/orchestration/src/utils/zoe-tools.js 65.43% <50.00%> (+0.43%) ⬆️
...s/orchestration/src/examples/sendAnywhere.flows.js 44.06% <20.00%> (ø)

... and 2 files with indirect coverage changes

@turadg turadg force-pushed the 9303-upgrade-testing-supports branch from f44917f to d374cd2 Compare July 25, 2024 00:16
Copy link
Member

@dckc dckc left a comment

Choose a reason for hiding this comment

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

very nice.

I'm not 100% confident that I grok "feat: defer inbound bridge messages" fully but I suppose the tests show that it works.

/**
* Elaboration of EVProxy with knowledge of bootstrap space in these tests.
*/
type BootstrapEV = EProxy & {
Copy link
Member

Choose a reason for hiding this comment

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

.ts 🥷

userSeat: ERef<UserSeat>;
userSeat: Promise<UserSeat>;
Copy link
Member

Choose a reason for hiding this comment

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

This excludes a remote presence for a UserSeat. That doesn't seem right. But I guess it could be a promise, so any consumers have to await it anyway. so close enough.

Copy link
Member Author

Choose a reason for hiding this comment

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

ERef is just T | Promise<T> and it's never just T. The remoteness is handled elsewhere.

@@ -40,7 +41,7 @@ import type { MsgDelegateResponse } from '@agoric/cosmic-proto/cosmos/staking/v1
import type { CoreEvalSDKType } from '@agoric/cosmic-proto/swingset/swingset.js';
import type { EconomyBootstrapPowers } from '@agoric/inter-protocol/src/proposals/econ-behaviors.js';
import type { SwingsetController } from '@agoric/swingset-vat/src/controller/controller.js';
import type { BridgeHandler, IBCMethod } from '@agoric/vats';
import type { BridgeHandler, IBCMethod, IBCPacket } from '@agoric/vats';
Copy link
Member

Choose a reason for hiding this comment

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

The vats package is really bursting at the seams, isn't it?

I wonder what it would cost to move IBCMethod, IBCPacket to network.

Comment on lines 440 to 442
// This is what it used to do but that's not valid because bridge responses
// aren't instantaneous.
// inbound(BridgeId.DIBC, icaMocks.channelOpenAck(obj));
Copy link
Member

Choose a reason for hiding this comment

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

we want to keep this?

Copy link
Member Author

Choose a reason for hiding this comment

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

just for code review. I'll drop it


t.log('restart stakeAtom');
await evalProposal(
buildProposal('@agoric/builders/scripts/testing/restart-stakeAtom.js'),
Copy link
Member

Choose a reason for hiding this comment

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

👏

Comment on lines +94 to +96
// import dynamically so the module can work in CoreEval environment
const dspModule = await import('@agoric/deploy-script-support');
Copy link
Member

Choose a reason for hiding this comment

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

interesting... I wonder how this doesn't run afoul of the SES prohibition on dynamic import.

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe agoric run isn't locked down so much?

Copy link
Member

Choose a reason for hiding this comment

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

But this whole module is bundled for use as the actual core-eval.

I suppose the import() gets "de-fanged" by deploy-script-support. It would probably fail if we tried to run this part of the code on-chain, but we don't.

@turadg turadg force-pushed the 9303-upgrade-testing-supports branch from d374cd2 to ab8f679 Compare July 25, 2024 14:15
@turadg turadg added the automerge:rebase Automatically rebase updates, then merge label Jul 25, 2024
@@ -371,8 +371,10 @@ type ChainBootstrapSpaceT = {
namesByAddress: import('../types.js').NameHub;
namesByAddressAdmin: import('../types.js').NamesByAddressAdmin;
networkVat: NetworkVat;
orchestration?: CosmosInterchainService;
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
orchestration?: CosmosInterchainService;
cosmosInterchainService?: CosmosInterchainService;
orchestrationVat?: OrchestrationVat;

In light of #9668

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a bigger change than just the typedef

Copy link
Member

Choose a reason for hiding this comment

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

I thought we don't have orchestration in chain bootstrap space anymore? But, these two are there?

* @param {ZCFSeat} seat
* @param {{ chainNames: string[] }} offerArgs
*/
const makePortfolioAcctHandler = async (
orch,
makePortfolioHolder,
{ makePortfolioHolder },
Copy link
Member

Choose a reason for hiding this comment

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

Had this in mind with the original implementation: #9591 (comment)

But that is platform code and this is an example contract. So, don't see any harm here

Comment on lines 30 to 31
const cosmosAccount = await remoteChain.makeAccount();
return cosmosAccount.asContinuingOffer();
Copy link
Member

Choose a reason for hiding this comment

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

If you find yourself needing to make fixups, mind including this drive-by?

- * Create an account on a Cosmos chain and return a continuing offer with
- * invitations makers for Delegate, WithdrawRewards, Transfer, etc.
+ * Create an OrchestrationAccount for a specific chain and return a continuing
+ * offer with invitations makers for Delegate, WithdrawRewards, Transfer, etc.
  *
  * @satisfies {OrchestrationFlow}
  * @param {Orchestrator} orch
@@ -30,8 +30,8 @@ const makeOrchAccountHandler = async (orch, _ctx, seat, { chainName }) => {
   seat.exit(); // no funds exchanged
   mustMatch(chainName, M.string());
   const remoteChain = await orch.getChain(chainName);
-  const cosmosAccount = await remoteChain.makeAccount();
-  return cosmosAccount.asContinuingOffer();
+  const orchAccount = await remoteChain.makeAccount();
+  return orchAccount.asContinuingOffer();
 };

{ makePortfolioHolder },
makePortfolioAcctHandler,
);
const orchFns = orchestrateAll(flows, { makePortfolioHolder });
Copy link
Member

Choose a reason for hiding this comment

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

These have different contexts - so it seems like 2x orchestrate is worth the cost here? Seems like it'll also be good to have examples using both orchestrateAll and orchestrate.

Copy link
Member Author

Choose a reason for hiding this comment

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

I vacillated on this but I don't see how providing makePortfolioHolder to both is a risk.

I think orchestrateAll is what we should steer people to in general because it gets the durable from a named export, which changing is known to break downstream, whereas the string argument was easily confused as a debugging name.

Copy link
Member

Choose a reason for hiding this comment

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

👍 the second argument is convincing

Comment on lines +338 to +356
setTimeout(() => {
/**
* Mock when Agoric receives the ack from another chain over DIBC. Always
* happens after the packet is returned.
*/
inbound(BridgeId.DIBC, msg);
});
Copy link
Member

Choose a reason for hiding this comment

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

👍 nice use of setTimeout here

Copy link
Member

Choose a reason for hiding this comment

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

ambient authority grumble...

Copy link
Member Author

Choose a reason for hiding this comment

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

ambient authority in a mock.

setTimeout(() => {
/**
* Mock when Agoric receives the ack from another chain over DIBC. Always
* happens after the packet is returned.
Copy link
Member

Choose a reason for hiding this comment

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

Should we also make a similar change in:

  • packages/orchestration/test/network-fakes.ts
  • packages/vats/tools/fake-bridge.js

Copy link
Member Author

Choose a reason for hiding this comment

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

I suppose so. WDYT @michaelfig ?

@@ -190,6 +197,7 @@ test.serial('stakeAtom - smart wallet', async t => {
encoding: 'bech32',
};

// This will trigger the immediate ack of the mock bridge
Copy link
Member

Choose a reason for hiding this comment

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

Is "This" related to executeOffer? It seems to be due to ackImmediately. Please consider making this comment more explicit

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried to word it in a way that wouldn't be false if that code was refactored

@turadg turadg added automerge:rebase Automatically rebase updates, then merge and removed automerge:rebase Automatically rebase updates, then merge labels Jul 25, 2024
@turadg turadg force-pushed the 9303-upgrade-testing-supports branch from ab8f679 to 07cf2e9 Compare July 25, 2024 14:35
@turadg turadg force-pushed the 9303-upgrade-testing-supports branch from 07cf2e9 to 816099a Compare July 25, 2024 18:42
@mergify mergify bot merged commit 0c96ea5 into master Jul 25, 2024
83 checks passed
@mergify mergify bot deleted the 9303-upgrade-testing-supports branch July 25, 2024 19:15
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.

3 participants