test of revising chain info #9552
Conversation
Deploying agoric-sdk with
|
| Latest commit: |
2f625b9
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ad7bc8a1.agoric-sdk.pages.dev |
| Branch Preview URL: | https://ta-revise-chain-info.agoric-sdk.pages.dev |
| const agoricAfter = await EV(agoricNames).lookup('chain', 'agoric'); | ||
| t.like(agoricAfter, { chainId: 'agoric-4' }); |
There was a problem hiding this comment.
Do we have requirements to handle changing a chainId change for a well-established chain? That's the sort of "earthquake" event that I think the market doesn't really contemplate. It would mean something like abandoning all the tokens that have ever gone over IBC to or from agoric-3. I'd rather not have a test that suggests that we handle this sort of thing. I'd much rather stick to "append only" changes to chain info (for a somewhat hand-wavy notion of append).
There was a problem hiding this comment.
I think we have a need to revise chain_id for Starship because it will have different ids for the names.
Since Starship is an E2E test, I'm fine relying on that actual test for whether the chain ids update as needed and taking this out of the test here that could be read as a product spec. I'll remove it.
There was a problem hiding this comment.
Ah. Yes, I look forward to supporting a chainId other than agoric-3 in the starship context. I'd expect it to go into agoricNames once as agoric-4 in the first place, though.
turadg
added
automerge:rebase
turadg
force-pushed
the
ta/revise-chain-info
branch
from
699f2b1
to
2f625b9
Compare
refs: #8896
Description
Extracted from #9534 to focus that PR on multichain and lighten the review. Also it had merge conflicts with master that this resolves.
Security Considerations
nothing new
Scaling Considerations
no
Documentation Considerations
none
Testing Considerations
new coverage
Upgrade Considerations
none