e2e testing capabilities for packet timeout scenarios #9891
Labels
enhancement
New feature or request
Comments
Merged
mergify bot
added a commit
that referenced
this issue
Aug 29, 2024
refs: #9068 refs: #9192 ## Description 1. Includes e2e tests of different channel closing behaviors added in #9857: - ~~Automatically reopen a closed ICA channel (e.g. a packet timed out)~~ requires #9891 to complete. See #9864 (comment) - `CosmosOrchestrationAccount` (`IcaAccout`) holder can close their account - `CosmosOrchestrationAccount` (`IcaAccount`) holder can reopen their account 2. Includes `publish local and remote ibc addresses to vstorage` to facilitate querying the ICA account (channel) info from an off-chain client. - NOTE: if an account is a reopened, the localAddress and remoteAddress originally published to vstorage will be stale. Same with some of the values stored in `CosmosOrchestrationAccountKit`'s exo state. The ChainAddress will be the same, but the full address strings will contain new channelIDs. This is tech debt being taken on until #9066. 3. Includes test to ensure clients cannot successfully submit `MsgChanCloseInit` for ICA and Transfer channels ### Security Considerations n/a ### Scaling Considerations n/a ### Documentation Considerations n/a ### Testing Considerations This PR includes high fidelity tests with simulated chains. ### Upgrade Considerations n/a
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
As an Orchestration API developer, I want to be able to test packet timeout (error) flows in an E2E environment (
/multichain-testing). Currently, capabilities for this sort of testing are only available in unit tests using mock bridges and fixtures.Description of the Design
TBD, but see the comments on this issue for some ideas.
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: