-
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
feat!: chainHub.getAsset
requires srcChainName
parameter
#10588
Conversation
dc416d2
to
d43db44
Compare
Deploying agoric-sdk with Cloudflare Pages
|
d280d69
to
c3403e5
Compare
Base branch is changed to master. Please re-run the integration tests by adding 'force:integration' label. |
1eed391
to
c12d868
Compare
This seems unrelated to these changes and is likely a flake. |
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.
this seems about right
@@ -146,6 +146,7 @@ export interface Orchestrator { | |||
IssuingChain extends keyof KnownChains, | |||
>( | |||
denom: Denom, | |||
holdingChainName: HoldingChain, |
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.
+cc @dtribble @mitdralla
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 is holdingChainName
constrained to a static list of known chains?
OK, I guess I see why for now. Tolerable tech debt, I suppose.
In due course, it seems like getDenomInfo
should be parameterized by...
getDenomInfo: <
HoldingChainInfo extends ChainInfo,
IssuingChainInfo extends ChainInfo,
>(
and maybe even the ConnectionInfo
between them.
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 is holdingChainName constrained to a static list of known chains?
Something to potentially solve in #9992. In the (stale) PR that attempted to close it, allowing string
for chainName
was an approach discussed.
const actual = orc.getDenomInfo('utoken1'); | ||
const actual = orc.getDenomInfo( | ||
'utoken1', | ||
// @ts-expect-error 'mock' not a KnownChain |
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.
doesn't seem like that should be an error
c12d868
to
aa03864
Compare
chainHub.getAsset
requires holdingChainName
parameterchainHub.getAsset
requires srcChainName
parameter
b4ce8f3
to
4464d37
Compare
4464d37
to
ba8aaa9
Compare
ba8aaa9
to
9638d57
Compare
- to facililate registering the same denom across multiple chains in `ChainHub` - denoms are unique to a chain, but not all chains
- since denoms are only unique to a chain and all chains, require `srcChainName` parameter for asset info lookups
- filed #10599 after observing multiple flakes from unrelated changes
9638d57
to
5912769
Compare
@mergify refresh |
✅ Pull request refreshed |
refs: #10445
Description
IBC Denoms are unique to a chain but not all not all chains. e.g., if
channel-0
points toosmosis
for two chains, theuosmo
denom will beibc/ED07A3391A112B175915CD8FAF43A2DA8E4790EDE12566649D0C2F97716B8518
for both.This change requires callers to specify the
holdingChainName
for the denom they wish to retrieve information about.Security Considerations
None
Scaling Considerations
None
Documentation Considerations
None
Testing Considerations
Updates existing tests. Motivated from work in #10571 which surfaced this issue.
Upgrade Considerations
Breaking change, but for library code that will be part on NPM or FUSDC release.