try re-enabling cosmwasm invariants #2958
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
### Description Addresses a handful of issues in #2865 ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
### Description
The old implementation of the `sequence_and_tip` fn in mailbox.rs used
to look like this, where it'd end up passing the tip as the lag!
```
let sequence = match NonZeroU64::new(tip as u64) {
None => None,
Some(n) => Some(self.nonce(Some(n)).await?),
};
```
Shuffled things around where we correctly just specify the `tip` as the
block number instead of a lag. This means that all functions that were
calling `wasm_query` with the lag needed to start getting the lagged
block num instead
Sometimes I believe this would create a bug where we'd ask for a block
height 1 and get back RPC errors. I believe most of the time we'd ask
for a block height of 0, in which case it'd just act like we were asking
for the tip
### Drive-by changes
n/a
### Related issues
n/a
### Backward compatibility
n/a
### Testing
plan to roll it out once I get an image
### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
### Description - Removes unwraps and expects from everywhere but `run-locally` - Precomputes the `address` in `Signer` at construction time, to propagate the error early and keep signatures ergonomic by not requiring a `Result`. Couldn't also precompile `SigningKey` (the privkey type) because it's not `Sync` 😢 - Defines a `hyperlane-cosmos`-specific error enum (`HyperlaneCosmosError`), which can be converted to `ChainCommunicationError` with the `?` operator. This is a pattern we'd like to refactor towards in the future, to remove dependencies from `hyperlane-core` as much as possible - One inconvenience is that you need to `.map_err()` to `HyperlaneCosmosError` first, to use `?`. I wish `?` had deref coercion semantics where it'd keep covnerting until an error matches, but I assume this isn't possible because while you can only have a single `Deref` impl, you can have multiple `From<Err>` impls. - Writing this I'm realising we could write a small macro to implement `From<Err> for ChainCommunicationError` for all the sub-errors of `HyperlaneCosmosError` et al (cc @tkporter)
…on Neutron (#2885) ### Description Hopeful quick fix to indexing issues we're seeing. Leading theory is that the tx_search is asking for a block range that the servicing RPC node doesn't actually have state for. Curious if @nambrot you feel we should go with a more conservative reorg period, maybe 2 blocks? My personal theory is that this isn't just bad RPC load balancing, but that the tip that's returned is simply committed to but the state transition hasn't yet been executed, see https://github.com/CosmWasm/cosmwasm/blob/main/SEMANTICS.md#sdk-context > First, the Tendermint engine will seek 2/3+ consensus on a list of transactions to be included in the next block. This is done without executing them. They are simply subjected to a minimal pre-filter by the Cosmos SDK module, to ensure they are validly formatted transactions, with sufficient gas fees, and signed by an account with sufficient fees to pay it. Notably, this means many transactions that error may be included in a block. > Once a block is committed (typically every 5s or so), the transactions are then fed to the Cosmos SDK sequentially in order to execute them. Each one returns a result or error along with event logs, which are recorded in the TxResults section of the next block. The AppHash (or merkle proof or blockchain state) after executing the block is also included in the next block. ### Drive-by changes Fix a typo for `CosmosMerkleTreeHookIndexer` ### Related issues n/a ### Backward compatibility non breaking ### Testing None 😛
### Description Moves merkle tree hook insertion indexing away from the watermarked contract sync to the same method that message indexing uses * Generalizes all the MessageContractSync / MessageSyncCursor etc to work with any "sequenced" data. Sequenced data means a data type that has a sequence # that increases 1 at a time as it's created. E.g. a message's nonce is its sequence, or a merkle tree insertion's leaf index is its sequence ### Drive-by changes Minor idiomatic changes ### Related issues n/a ### Backward compatibility I believe this is fully backward compatible ### Testing Tested locally by running a relayer with an empty data dir & with an existing data dir. Also tested a validator locally
### Description * Stops creating a new client a bunch of times in rpc.rs (I haven't yet changed grpc.rs - this is because the client's functions are `&mut self`, so will have to think about what to do here) * Changes `unwrap_or_none_result` to not include the `let Some(varname)` bit so we can do `let varname = unwrap_or_none_result!(...)` * Instead of a `get_parser(&self, ...)` fn that returns a closure, we just pass a the function `Self::[data_type]_parser` * Refactors these parsers to be a bit more defensive - e.g. each param is represented as an Option so it's clear if one isn't parsed, and we also get the `_contract_address` param (which is auto-set by the cosmwasm runtime). It returns a `ParsedEvent<T>` so that we can return the `_contract_address` in there too * Refactors the range indexing in rpc.rs, including an important fix to ensure that the contract address of an event is the one we actually want to index ### Drive-by changes n/a ### Related issues n/a ### Backward compatibility Fully ### Testing Unit tests, ran locally
### Description Delegates bech32 encoding, decoding, and cosmos address building from a private key to cosmrs/tendermint upstream crates. The only place where this wasn't doable was the tests, because of a cyclic dependency - left a TODO comment there. As part of this, renamed `rust/chains/hyperlane-cosmos/src/libs/verify.rs` -> `rust/chains/hyperlane-cosmos/src/libs/address.rs` ~~**Warning**: We should re-enable e2e and make sure everything still works locally, since the actual `encode`/`decode` functions that end up being called _are_ different~~ ### Testing Tested manually EVM <> Duality (both ways)
Removes cosmos signer unwraps by making the signer optional. Depends on #2887
### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
### Description * Creates a single channel that's cloned (which can be done [cheaply and is encouraged](https://docs.rs/tonic/latest/tonic/transport/struct.Channel.html)) when creating a new client. * general cleanup & renaming * I believe a chain signer will not be required by e.g. the validator, will confirm this locally ### Drive-by changes n/a ### Related issues n/a ### Backward compatibility yee ### Testing builds, local test
Size of rust build exceeds the storage space in the `ubuntu-latest` runner. `larger-runner` has more storage, but let's see if it also has all the system dependencies required to build
Adds "gas payment count" and "confirmed submitted messages" as termination invariants to the cw run-locally, to get the test to actually fail if messages are not delivered
### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
|
|
@daniel-savu hope you dont mind me closing this |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening to see if fixing the wasm check also fixes the ubuntu ci