-
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
test: continuing offers in orchestrate async-flows #9679
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
10264b8
to
a404135
Compare
* @file Primarily a testing fixture, but also serves as an example of how to | ||
* leverage basic functionality of the Orchestration API with async-flow. | ||
*/ |
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.
Feedback welcome if anyone can think of a better name than kitchen-sink
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.
A kitchen sink will be some effort to maintain. Whenever we add some functionality we'll test it in a targeted fashion and have to also include it here.
If the scope is to test async flow, maybe "stress-flows" or "basic-flows"
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.
Thanks, I will go with basic-flows
. Will make this change in the final rebase after ✅ if that's ok
@@ -1938,26 +1931,6 @@ __metadata: | |||
languageName: node | |||
linkType: hard | |||
|
|||
"eslint-plugin-prettier@npm:^5.1.3": |
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.
How / when can we make the Multichain E2E Testing job part of force-integration
?
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.
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.
* @file Primarily a testing fixture, but also serves as an example of how to | ||
* leverage basic functionality of the Orchestration API with async-flow. | ||
*/ |
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.
A kitchen sink will be some effort to maintain. Whenever we add some functionality we'll test it in a targeted fashion and have to also include it here.
If the scope is to test async flow, maybe "stress-flows" or "basic-flows"
mustMatch(chainName, M.string()); | ||
const remoteChain = await orch.getChain(chainName); | ||
const cosmosAccount = await remoteChain.makeAccount(); | ||
// @ts-expect-error asContinuingOffer does not exist on OrchestrationAccountI |
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.
why not? you did add it to orchestrationAccountMethods
. Those lists must be the same:
agoric-sdk/packages/orchestration/src/utils/orchestrationAccount.js
Lines 11 to 22 in 21742bd
/** @see {OrchestrationAccountI} */ | |
export const orchestrationAccountMethods = { | |
getAddress: M.call().returns(ChainAddressShape), | |
getBalance: M.call(M.any()).returns(Vow$(CoinShape)), | |
getBalances: M.call().returns(Vow$(M.arrayOf(CoinShape))), | |
send: M.call(ChainAddressShape, AmountArgShape).returns(VowShape), | |
transfer: M.call(AmountArgShape, ChainAddressShape) | |
.optional(M.record()) | |
.returns(VowShape), | |
transferSteps: M.call(AmountArgShape, M.any()).returns(VowShape), | |
asContinuingOffer: M.call().returns( | |
Vow$({ |
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 meant to come back to this. Addressed in the batch of fixups via orchestration-api.ts
.
Feedback on the JS Doc comments is appreciated. Our docs are a bit light on these subjects but this seemed like a good place to over-explain a little.
packages/orchestration/src/exos/cosmos-orchestration-account.js
Outdated
Show resolved
Hide resolved
account: { | ||
description: PUBLIC_TOPICS.account[0], | ||
subscriber: topicKit.subscriber, | ||
// eslint-disable-next-line @jessie.js/safe-await-separator |
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.
please include justification
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.
Perhaps too naively, we don't care if this crosses a turn boundary. We don't expect the answer to storagePath to change.
I was a little intimidated by the phrasing in the eslint config and have reverted:
Lines 111 to 112 in df05b07
// that are used by multiple clients. So we enable it throughout the repo | |
// and aim for no exceptions. |
contractName: 'kitchenSink', | ||
wallet: accounts[0], | ||
}; | ||
test.serial(`Create account on ${chainName}`, makeAccountScenario, scenario); |
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.
consider using the test.macro
's title maker and just passing the literals needed to lookup the rest. Then you don't need a loop. e.g.
test.serial(makeAccountScenario, 'agoric');
test.serial(makeAccountScenario, 'cosmoshub');
test.serial(makeAccountScenario, 'osmosis');
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.
Thanks for the push to refactor the test. It led to simplifying the contract!
asContinuingOffer: () => Promise<ContinuingOfferResult>; | ||
/** | ||
* Public topics are a map to different vstorage paths and subscribers that | ||
* can be shared with on or offchain clients. | ||
* When returned as part of a continuing invitation, it will appear | ||
* in the {@link CurrentWalletRecord} in vstorage. | ||
*/ | ||
getPublicTopics: () => Promise<TopicsRecord>; |
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.
these are top level API changes that should have @dtribble approval. I approve and will leave to you how/when to sync with Dean
7376204
to
4087da7
Compare
- previously, each orch account was given the contracts storage node. this creates a child node per account - refs #9066, helping ensure orch account addresses are available for smart-wallet clients. left some suggestions in code comments for further improvements
- update PublicTopic.storagePath on async-flow endowments to return a string instead of a promise. Uses asVow with async function since it's reasonable to assume the remote call will resolve promptly (in the same run) - update asContinuingOffer to return a vow and unwrap the result of getPublicTopic since this is also a vow. same promptness considerations mentioned above apply - closes: #9673
- seem like it was missed in #9664, but not caught since this job runs after merges to master
4087da7
to
13a66e0
Compare
- tests a contract that uses orchestrate/async-flow in the multichain-testing environment
- fixes changed parameter from #9662 - improves test to print delegate offer result error on failure
13a66e0
to
b7a9ed3
Compare
@@ -7,7 +7,7 @@ export { SubscriberShape }; | |||
export const PublicTopicShape = M.splitRecord( | |||
{ | |||
subscriber: SubscriberShape, | |||
storagePath: M.promise(/* string */), | |||
storagePath: M.or(M.promise(/* string */), M.string()), |
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.
As we discussed, changing this shape is safe against upgrade as it couldn't have been used as a durable state of collection shape before because durably storing promises is not possible.
closes: #9673
refs: #9066
refs: #9042
Description
basic-flow.contract.js
, proposal, and builder for testingorchestrate
(async-flow
) continuing invitations to facilitate testing. These are also the first bootstrap + multichain tests withorchestrate
/async-flow
.asContinuingInvitation
andgetPublicTopics
methods to return Vows to satisfy membrane constraintsstoragePath
, part ofContinuingOfferResult
is a string instead of a Promise/Vow sosmart-wallet
can easily handle this and theasync-flow
membrane is appeased (no promises)Testing Considerations
Includes unit, bootstrap, and multichain (e2e) tests for an async-flow contract. E2E ensure accounts can be created on agoric, cosmos, and osmosis and return continuing invitations.
Upgrade Considerations
This did not require any changes to smart-wallet. There is a change to
PublicTopicShape
to accept a promise or a string (previously just a promise), but this is only in contracts relaying on smart-wallet, not smart-wallet itself.