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

9281 chainHub exo #9538

Merged
merged 2 commits into from
Jun 19, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 32 additions & 1 deletion packages/orchestration/src/exos/chain-hub.js
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,38 @@ export const connectionKey = (chainId1, chainId2) => {
return [chainId1, chainId2].sort().join(CHAIN_ID_SEPARATOR);
};

const ChainIdArgShape = M.or(
Copy link
Member

Choose a reason for hiding this comment

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

consider:

Suggested change
const ChainIdArgShape = M.or(
/** accepts `chainId` or `ChainAddress` object */
const ChainIdArgShape = M.or(

Copy link
Member Author

Choose a reason for hiding this comment

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

good idea. I'll make a note to get that into a future PR

M.string(),
M.splitRecord(
{
chainId: M.string(),
},
undefined,
M.any(),
),
);

const ChainHubI = M.interface('ChainHub', {
registerChain: M.call(M.string(), CosmosChainInfoShape).returns(),
getChainInfo: M.callWhen(M.string()).returns(CosmosChainInfoShape),
registerConnection: M.callWhen(
M.string(),
M.string(),
IBCConnectionInfoShape,
).returns(),
getConnectionInfo: M.callWhen(ChainIdArgShape, ChainIdArgShape).returns(
Copy link
Member

Choose a reason for hiding this comment

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

callWhen is OK in asyncFlow after all?

I can imagine waiting for tests that show that it's not, but in that case, why not wait for tests that show that chainHub has to be an exo in the 1st place?

Copy link
Member Author

@turadg turadg Jun 20, 2024

Choose a reason for hiding this comment

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

Nope, I learned last night it's not.

We did hit a test failure with the object itself not being durable but only in another branch that had a higher fidelity asyncFlow

IBCConnectionInfoShape,
),
});

/**
* Make a new ChainHub in the zone (or in the heap if no zone is provided).
*
* The resulting object is an Exo singleton. It has no precious state. It's only
* state is a cache of queries to agoricNames and whatever info was provided in
* registration calls. When you need a newer version you can simply make a hub
* hub and repeat the registrations.
*
* @param {Remote<NameHub>} agoricNames
* @param {Zone} [zone]
*/
Expand All @@ -70,7 +101,7 @@ export const makeChainHub = (agoricNames, zone = makeHeapZone()) => {
valueShape: IBCConnectionInfoShape,
});

const chainHub = harden({
const chainHub = zone.exo('ChainHub', ChainHubI, {
/**
* Register a new chain. The name will override a name in well known chain
* names.
Expand Down
Loading