feat: update to 1.18#62
Conversation
* due to HumanReadableUpgradeBlockHeightPerChainID set to 490 currently for devnet chain ids, we need to prevent this from happening for the first blocks * hopefully can remove this again in the future
|
No actionable comments were generated in the recent review. 🎉 📝 WalkthroughWalkthroughThis PR releases version 1.18.0 of injective-test-tube, updating dependencies (including CosmWasm-std, test-tube-inj, and Cosmos SDK modules), adding new exchange module parameters for post-only mode trading, replacing denomination decimals configuration with auction-specific decimals handling, introducing open_notional_cap support in exchange proposals, removing the relay_band_rates oracle endpoint, and updating corresponding test data and parameter initialization. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@packages/injective-test-tube/Cargo.toml`:
- Around line 28-30: The [patch.crates-io] section in this member Cargo.toml
(which overrides cosmos-sdk-proto = "0.27.0" and tendermint-proto = "0.40.4")
must be moved to the workspace root Cargo.toml because Cargo ignores patch
sections in non-root workspace members; remove the [patch.crates-io] block from
this file and add the same entries under a single [patch.crates-io] section in
the workspace root Cargo.toml so the overrides for cosmos-sdk-proto and
tendermint-proto take effect.
In `@packages/injective-test-tube/CHANGELOG.md`:
- Around line 8-14: The changelog entry "## 1.18.0-beta.2 - 2026-06-20" has a
release date in the future; confirm and update the date or mark it as TBD. Edit
the header for the release version "1.18.0-beta.2" (the line containing
"1.18.0-beta.2 - 2026-06-20") to either the correct intended YYYY-MM-DD date or
replace the date portion with "TBD" (e.g., "1.18.0-beta.2 - TBD") and ensure the
bumped packages (`injective-core@v1.18.0-beta.2`,
`injective-std@=1.18.0-beta.2`) remain unchanged.
In `@packages/test-tube/src/runner/app.rs`:
- Around line 339-343: The long, poorly formatted expression building
cosmrs::Coin (variable amount) should be simplified and formatted: extract the
nested gas price conversion into a well-named local variable (e.g., let
gas_price_u128 = gas_price.amount.to_string().parse::<u128>().unwrap();),
compute the fee amount using that local value and gas_limit with clear
intermediate steps, and then construct cosmrs::Coin using those locals
(referencing fee_denom, gas_limit, gas_price.amount, and variable amount).
Reformat the block to keep lines short and run cargo fmt to fix the pipeline
formatting error.
🧹 Nitpick comments (2)
packages/injective-test-tube/src/runner/app.rs (1)
494-497: Make the Uint256 subtraction explicit to avoid trait mismatches.This avoids relying on
Uint256 - Uint128operator support acrosscosmwasm-stdversions.♻️ Suggested tweak
- assert_eq!( - Uint256::new(bob_balance), - Uint256::new(initial_balance) - amount.amount - ); + assert_eq!( + Uint256::new(bob_balance), + Uint256::new(initial_balance) - Uint256::new(amount.amount.u128()) + );packages/injective-test-tube/src/module/wasm.rs (1)
68-74: Simplify amount string conversion.
format!("{}", c.amount.to_string())is redundant;c.amount.to_string()is sufficient.♻️ Suggested cleanup
- amount: format!("{}", c.amount.to_string()), + amount: c.amount.to_string(),Also applies to: 95-100
| [patch.crates-io] | ||
| cosmos-sdk-proto = { version = "0.27.0" } | ||
| tendermint-proto = { version = "0.40.4" } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the workspace root and structure
find . -maxdepth 2 -name "Cargo.toml" -type f | head -20Repository: InjectiveLabs/test-tube
Length of output: 79
🏁 Script executed:
# Check the specific file mentioned in the review
cat -n packages/injective-test-tube/Cargo.toml | head -50Repository: InjectiveLabs/test-tube
Length of output: 1401
🏁 Script executed:
# Check the root Cargo.toml to see if it's a workspace
cat -n ./Cargo.toml | head -40Repository: InjectiveLabs/test-tube
Length of output: 158
🏁 Script executed:
# Look for any CI/pipeline configuration files that might have warnings
find . -maxdepth 2 -type f \( -name "*.yml" -o -name "*.yaml" -o -name ".github" -o -name ".gitlab-ci.yml" \) 2>/dev/null | head -20Repository: InjectiveLabs/test-tube
Length of output: 49
🏁 Script executed:
# Check if the root Cargo.toml has any patch sections
grep -A 10 "\[patch" ./Cargo.tomlRepository: InjectiveLabs/test-tube
Length of output: 49
🏁 Script executed:
# Check if there are any other Cargo.toml files in the packages directory
find packages -name "Cargo.toml" -type fRepository: InjectiveLabs/test-tube
Length of output: 136
🏁 Script executed:
# Check the other package's Cargo.toml to see if it also has patch sections
cat -n packages/test-tube/Cargo.toml | grep -A 5 "\[patch"Repository: InjectiveLabs/test-tube
Length of output: 49
🌐 Web query:
Cargo patch section non-root workspace member behavior
💡 Result:
In Cargo workspaces, [patch] (as well as [replace] and [profile.*]) is only read from the workspace root manifest (the Cargo.toml that contains [workspace]). If you put a [patch] section in a non-root workspace member’s Cargo.toml, Cargo ignores it. [1]
Implications:
- Running
cargo buildinside a member crate still uses the workspace root’s[patch], because Cargo finds the workspace root and uses that manifest’s patch settings. [1] - If you depend on some crate (e.g., via
git = ...) that itself is a workspace and has[patch]in its root, those patches do not “travel” as transitive config. Only the top-level workspace you are building can define patches that apply to the build. So you must duplicate the needed[patch]in your workspace root if you want it applied. [2]
Sources:
[1] Cargo Book: Workspaces — only root manifest recognizes [patch] (member manifests ignored) https://dev-doc.rust-lang.org/nightly/cargo/reference/workspaces.html
[2] Rust forum confirmation: [patch] only used from the top-level package/workspace you are building https://users.rust-lang.org/t/patch-section-doesnt-get-applied-for-a-dependency-from-workspace/50377
Move [patch.crates-io] to the workspace root.
Cargo ignores patch sections in non-root workspace members per the official Cargo documentation. These overrides have no effect and must be relocated to the root Cargo.toml at the workspace level to be applied.
🧭 Suggested local cleanup
-[patch.crates-io]
-cosmos-sdk-proto = { version = "0.27.0" }
-tendermint-proto = { version = "0.40.4" }🤖 Prompt for AI Agents
In `@packages/injective-test-tube/Cargo.toml` around lines 28 - 30, The
[patch.crates-io] section in this member Cargo.toml (which overrides
cosmos-sdk-proto = "0.27.0" and tendermint-proto = "0.40.4") must be moved to
the workspace root Cargo.toml because Cargo ignores patch sections in non-root
workspace members; remove the [patch.crates-io] block from this file and add the
same entries under a single [patch.crates-io] section in the workspace root
Cargo.toml so the overrides for cosmos-sdk-proto and tendermint-proto take
effect.
| ## 1.18.0-beta.2 - 2026-06-20 | ||
|
|
||
| ### Changed | ||
|
|
||
| - Bumped `injective-core@v1.18.0-beta.2` | ||
| - Bumped `injective-std@=1.18.0-beta.2` | ||
| - Beta Release - Not available in public |
There was a problem hiding this comment.
Confirm the release date (currently in the future).
The entry is dated June 20, 2026, which is after today (Feb 9, 2026). Please confirm the intended date or mark it as TBD.
🤖 Prompt for AI Agents
In `@packages/injective-test-tube/CHANGELOG.md` around lines 8 - 14, The changelog
entry "## 1.18.0-beta.2 - 2026-06-20" has a release date in the future; confirm
and update the date or mark it as TBD. Edit the header for the release version
"1.18.0-beta.2" (the line containing "1.18.0-beta.2 - 2026-06-20") to either the
correct intended YYYY-MM-DD date or replace the date portion with "TBD" (e.g.,
"1.18.0-beta.2 - TBD") and ensure the bumped packages
(`injective-core@v1.18.0-beta.2`, `injective-std@=1.18.0-beta.2`) remain
unchanged.
| let amount = cosmrs::Coin { | ||
| denom: self.fee_denom.parse().unwrap(), | ||
| amount: (((gas_limit as f64) * (gas_price.amount.u128() as f64)).ceil() as u64) | ||
| amount: (((gas_limit as f64) * (gas_price.amount.to_string().parse::<u128>().unwrap() as f64)).ceil() as u64) | ||
| .into(), | ||
| }; |
There was a problem hiding this comment.
Fix formatting and improve readability.
The pipeline reports a formatting error on this code. Additionally, the line is quite long and the nested conversions make it hard to follow.
Consider extracting the gas price conversion to a local variable for clarity:
Proposed fix
- let amount = cosmrs::Coin {
- denom: self.fee_denom.parse().unwrap(),
- amount: (((gas_limit as f64) * (gas_price.amount.to_string().parse::<u128>().unwrap() as f64)).ceil() as u64)
- .into(),
- };
+ let gas_price_u128: u128 = gas_price.amount.to_string().parse().unwrap();
+ let fee_amount =
+ ((gas_limit as f64) * (gas_price_u128 as f64)).ceil() as u64;
+ let amount = cosmrs::Coin {
+ denom: self.fee_denom.parse().unwrap(),
+ amount: fee_amount.into(),
+ };Run cargo fmt to resolve the pipeline failure.
🤖 Prompt for AI Agents
In `@packages/test-tube/src/runner/app.rs` around lines 339 - 343, The long,
poorly formatted expression building cosmrs::Coin (variable amount) should be
simplified and formatted: extract the nested gas price conversion into a
well-named local variable (e.g., let gas_price_u128 =
gas_price.amount.to_string().parse::<u128>().unwrap();), compute the fee amount
using that local value and gas_limit with clear intermediate steps, and then
construct cosmrs::Coin using those locals (referencing fee_denom, gas_limit,
gas_price.amount, and variable amount). Reformat the block to keep lines short
and run cargo fmt to fix the pipeline formatting error.
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/injective-test-tube/src/module/helpers.rs (1)
44-58:⚠️ Potential issue | 🔴 CriticalReplace
exchange::v2withexchange::v1beta1for governance proposals.The governance module only accepts
/injective.exchange.v1beta1.MsgUpdateParams, not/injective.exchange.v2.MsgUpdateParams. Exchange "V2" in SDKs refers to indexer/API formats, not the on-chain proto package. Using v2 will cause the proposal to be rejected by the chain. Change the import and usage to:exchange::v1beta1, ... v1beta1::MsgUpdateParams::TYPE_URL🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/injective-test-tube/src/module/helpers.rs` around lines 44 - 58, The proposal is using the wrong proto package (v2) for on-chain governance; replace usages of v2::MsgUpdateParams with exchange::v1beta1::MsgUpdateParams and update the TYPE_URL reference accordingly (e.g., v1beta1::MsgUpdateParams::TYPE_URL) where the Any message is constructed (the encode call that fills buf and the Any { type_url: ..., value: buf } passed into MsgSubmitProposal) so the proposal uses /injective.exchange.v1beta1.MsgUpdateParams.
🧹 Nitpick comments (1)
packages/injective-test-tube/libinjectivetesttube/testenv/setup.go (1)
156-170: Avoid magic-number drift between InitialHeight and context Height.Define a single
initialHeightconstant and derive the context height from it to prevent off‑by‑one mismatches if the value changes later.♻️ Suggested refactor
- now := time.Now().UTC() + now := time.Now().UTC() + const initialHeight int64 = 500 _, err = appInstance.InitChain( &abci.InitChainRequest{ ChainId: "injective-777", Validators: []abci.ValidatorUpdate{}, ConsensusParams: DefaultConsensusParams, AppStateBytes: stateBytes, Time: now, - InitialHeight: 500, + InitialHeight: initialHeight, }, ) - ctx := appInstance.NewUncachedContext(false, cmtproto.Header{Height: 499, ChainID: "injective-777", Time: now}) + ctx := appInstance.NewUncachedContext(false, cmtproto.Header{Height: initialHeight - 1, ChainID: "injective-777", Time: now})🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/injective-test-tube/libinjectivetesttube/testenv/setup.go` around lines 156 - 170, The InitChain call uses a hardcoded InitialHeight (500) while NewUncachedContext uses a different hardcoded header Height (499); introduce a single named variable (e.g., initialHeight) and use it for both the abci.InitChain.InitialHeight and when constructing the header passed to appInstance.NewUncachedContext (derive context header height from initialHeight as appropriate) so they stay consistent; update references around InitChain, InitialHeight and NewUncachedContext/ctx to use that variable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/injective-test-tube/Cargo.toml`:
- Line 26: Update the cw1-whitelist dependency in Cargo.toml back to version
2.0.0 to align with the CosmWasm 2.x ecosystem used by cosmwasm-std = "3.0.2";
locate the cw1-whitelist entry (cw1-whitelist = "1.1.2") and change it to 2.0.0
so the crate versions are consistent with CosmWasm 2.0+.
- Around line 14-16: The Cargo.toml currently pins incompatible dependency
versions: injective-std = "=1.18.0" conflicts with cosmwasm-std = "3.0.2"
(injective-std v1.14.1 expects cosmwasm-std 2.1.0); confirm whether "1.18.0" is
a published crate or an internal/chain version and then make one of two fixes:
either set cosmwasm-std back to a version compatible with injective-std (e.g.,
2.1.0) or update injective-std to a published version that supports cosmwasm-std
3.0.2 (if available), updating the Cargo.toml dependency entries for
injective-std and/or cosmwasm-std accordingly and removing the restrictive "="
pin if it’s not a valid crate version.
- Around line 19-20: The crate's explicit serde pin (serde = "1.0.144") is
forcing serde_json to be downgraded; update the Cargo.toml for
injective-test-tube to allow serde >= 1.0.194 (e.g., change the serde dependency
from "1.0.144" to "1.0.194" or a compatible caret range like ">=1.0.194" /
"^1.0.194") and then restore or remove the hardcoded serde_json = "1.0.85" so
the resolver can select serde_json 1.0.140 (matching test-tube) and satisfy
cosmwasm-std 3.0.2's serde >=1.0.192 constraint.
In `@packages/injective-test-tube/libinjectivetesttube/go.mod`:
- Line 38: The go.mod currently pins the dependency
"github.com/ethereum/go-ethereum v1.16.3 // indirect" which is vulnerable;
update that module line to "github.com/ethereum/go-ethereum v1.17.0"
(recommended) or at minimum "v1.16.9", run go mod tidy to refresh the module
graph and rebuild/test the project (fix any API changes), and if you must remain
on ≤v1.16.8 remember to rotate the node key at <datadir>/geth/nodekey; target
the exact module line "github.com/ethereum/go-ethereum v1.16.3 // indirect" when
applying the change.
---
Outside diff comments:
In `@packages/injective-test-tube/src/module/helpers.rs`:
- Around line 44-58: The proposal is using the wrong proto package (v2) for
on-chain governance; replace usages of v2::MsgUpdateParams with
exchange::v1beta1::MsgUpdateParams and update the TYPE_URL reference accordingly
(e.g., v1beta1::MsgUpdateParams::TYPE_URL) where the Any message is constructed
(the encode call that fills buf and the Any { type_url: ..., value: buf } passed
into MsgSubmitProposal) so the proposal uses
/injective.exchange.v1beta1.MsgUpdateParams.
---
Duplicate comments:
In `@packages/injective-test-tube/Cargo.toml`:
- Around line 28-30: The [patch.crates-io] stanza in the member manifest (the
Cargo.toml containing the patch.crates-io block for cosmos-sdk-proto and
tendermint-proto) is ignored because patch rules must live in the workspace
root; remove this duplicate stanza from the member Cargo.toml and add (or
update) a single [patch.crates-io] section in the workspace root Cargo.toml with
the entries cosmos-sdk-proto = { version = "0.27.0" } and tendermint-proto = {
version = "0.40.4" } so the override applies to all workspace members (then run
cargo build/cargo metadata to verify the patch is picked up).
---
Nitpick comments:
In `@packages/injective-test-tube/libinjectivetesttube/testenv/setup.go`:
- Around line 156-170: The InitChain call uses a hardcoded InitialHeight (500)
while NewUncachedContext uses a different hardcoded header Height (499);
introduce a single named variable (e.g., initialHeight) and use it for both the
abci.InitChain.InitialHeight and when constructing the header passed to
appInstance.NewUncachedContext (derive context header height from initialHeight
as appropriate) so they stay consistent; update references around InitChain,
InitialHeight and NewUncachedContext/ctx to use that variable.
| cosmwasm-std = { version = "3.0.2", features = [ "cosmwasm_1_2", "cosmwasm_1_3", "cosmwasm_1_4", "cosmwasm_2_0", "iterator", "stargate" ] } | ||
| injective-cosmwasm = { version = "0.3.5-1" } | ||
| injective-std = { version = "=1.18.0" } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
cosmwasm-std 3.0.2 release notes features breaking changes
💡 Result:
cosmwasm-std 3.0.2 release notes (CosmWasm workspace release)
What’s new / changed in 3.0.2 (tagged 2025-08-26)
3.0.2 is primarily a maintenance/documentation/tooling release across the CosmWasm monorepo (which includes cosmwasm-std 3.0.2). Notable items include:
- Added/fixed crate-level docs across crates; minor maintenance fixes; unified security policy; updated copyright notice. [1]
- Repo/tooling work: CircleCI → GitHub Actions migration, removing unused config files, enabling PR checks, formatting/unifying
Cargo.toml, initial Task script, README updates, local dependency paths, unified dependencies. [1] - Crypto dependency pin:
ed25519-zebrafixed to=4.0.3. [1]
Breaking changes in 3.0.2 itself: none called out (it’s a patch release focused on maintenance). [1]
Features & breaking changes you’ll hit when moving to 3.0.x (from 2.x)
Most “real” feature additions and breaking changes land in 3.0.0, so they apply to 3.0.2 as part of the 3.0 line.
Key features in 3.0.x (highlights)
- IBCv2 support: new messages/entrypoints/types (e.g.,
Ibc2Msg, new IBCv2 packet handling entrypoints). [1][3] - New query:
WasmQuery::RawRangefor raw storage range queries. [1][3] - Testing:
cosmwasm_std::testing::Envsfactory for easierEnvcreation/customization. [1] - Transaction hash in
TransactionInfo. [1][3]
Breaking changes / required migrations (common gotchas)
Coin::amountchanged fromUint128→Uint256(expect downstream math/type changes). [2]- Removed unbounded/unsafe queries:
BankQuery::AllBalancesandIbcQuery::ListChannels(no direct replacement; redesign required). [2] StdErrorredesign: many constructors removed; useStdError::msg(...)and?conversions;StdErrorno longer implementsError(affectsanyhow::Resultpatterns). [2]- Removed older deprecated JSON helpers (
from_slice,from_binary,to_vec,to_binary) → usefrom_json,to_json_vec,to_json_binary. [2] TransactionInfoandGovMsgare nownon_exhaustive(avoid exhaustive destructuring/matching). [2]- If using
cosmwasm-stdwithdefault-features = falsein a contract, you now must enable theexportsfeature. [2] abortfeature can be removed (panic handler always enabled);craneliftfeature removed. [2]
Sources: CosmWasm CHANGELOG (includes cosmwasm-std) [1], official migration guide for 2.x → 3.0.x [2], CosmWasm 3.0 release overview [3].
🌐 Web query:
injective-std 1.18.0 cosmwasm-std compatibility requirements
💡 Result:
injective-std v1.18.0 does not appear to be a published crate version on docs.rs/crates.io at the moment (the v1.18.0 you may be seeing in Injective materials refers to the Injective Chain (injectived) upgrade, not the Rust crate). [2]
For the latest published injective-std (v1.14.1), the compatibility requirement is:
cosmwasm-std = 2.1.0, with these features enabled:
abort,iterator,stargate,cosmwasm_1_2,cosmwasm_1_3,cosmwasm_1_4,cosmwasm_2_0. [1]
So, to be compatible (and avoid dual cosmwasm-std versions in your dependency graph), your contract should use cosmwasm-std 2.1.x (ideally 2.1.0 to match exactly), and enable any CosmWasm capability features you rely on. [1]
Sources: [1] [2]
🌐 Web query:
cosmwasm-std 3.0.2 cosmwasm_1_2 cosmwasm_1_3 cosmwasm_1_4 cosmwasm_2_0 feature flags compatibility
💡 Result:
In cosmwasm-std = 3.0.2, the cosmwasm_* feature flags are cumulative (each higher one enables the previous ones): cosmwasm_1_2 → cosmwasm_1_1, cosmwasm_1_3 → cosmwasm_1_2, cosmwasm_1_4 → cosmwasm_1_3, cosmwasm_2_0 → cosmwasm_1_4 (and so on). You generally enable the minimum flag that matches the oldest chain you need to support. [1]
What each flag means for chain compatibility
Enabling one of these flags makes your compiled contract require that runtime capability on the target chain (i.e., the chain/wasm module must advertise/support it). wasmd’s compatibility table shows support like this: [2]
cosmwasm_1_2is supported on wasmd ≥ 0.41 [2]cosmwasm_1_3is supported on wasmd ≥ 0.42 [2]cosmwasm_1_4is supported on wasmd ≥ 0.42 [2] (CosmWasm 1.4 was released with/for wasmd 0.42) [3]cosmwasm_2_0is supported on wasmd ≥ 0.51 [2] (CosmWasm 2.0 shipped as part of wasmd 0.51) [4]
Practical guidance
- If you need to run on CosmWasm 1.x chains, don’t enable
cosmwasm_2_0; use the highest 1.x flag you truly need (often none, orcosmwasm_1_2/1_3/1_4). - If you enable
cosmwasm_2_0, you’re targeting CosmWasm 2.0-capable chains (e.g., wasmd ≥ 0.51). [2][4]
Cargo examples
cosmwasm-std = { version = "3.0.2", default-features = false, features = ["std", "cosmwasm_1_4"] }
# or for CW2 chains:
# features = ["std", "cosmwasm_2_0"]Sources: cosmwasm-std 3.0.2 feature definitions [1]; wasmd capability/compatibility table [2]; CosmWasm 1.4 / wasmd 0.42 note [3]; CosmWasm 2.0 / wasmd 0.51 note [4].
Fix incompatible dependency versions—injective-std 1.18.0 does not appear to exist as a published crate.
The latest published injective-std (v1.14.1) requires cosmwasm-std = 2.1.0, not 3.0.2. Using cosmwasm-std 3.0.2 will create a dependency conflict. Confirm the correct version for injective-std (verify whether 1.18.0 is an internal/chain version, not a Rust crate) and either downgrade cosmwasm-std to 2.1.0 or update injective-std to a version compatible with 3.0.2 if available.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/injective-test-tube/Cargo.toml` around lines 14 - 16, The Cargo.toml
currently pins incompatible dependency versions: injective-std = "=1.18.0"
conflicts with cosmwasm-std = "3.0.2" (injective-std v1.14.1 expects
cosmwasm-std 2.1.0); confirm whether "1.18.0" is a published crate or an
internal/chain version and then make one of two fixes: either set cosmwasm-std
back to a version compatible with injective-std (e.g., 2.1.0) or update
injective-std to a published version that supports cosmwasm-std 3.0.2 (if
available), updating the Cargo.toml dependency entries for injective-std and/or
cosmwasm-std accordingly and removing the restrictive "=" pin if it’s not a
valid crate version.
| serde_json = "1.0.85" | ||
| test-tube-inj = { version = "2.0.9-1", path = "../test-tube" } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check the current state of the Cargo.toml file and see if there's any context
cat -n packages/injective-test-tube/Cargo.toml | head -30Repository: InjectiveLabs/test-tube
Length of output: 1381
🏁 Script executed:
# Check git history for this file to see when/why the version was changed
cd packages/injective-test-tube && git log --oneline -20 -- Cargo.tomlRepository: InjectiveLabs/test-tube
Length of output: 98
🏁 Script executed:
# Search for MSRV or rust-version constraints in the workspace
fd -t f "Cargo.toml" | xargs grep -l "rust-version\|msrv" 2>/dev/null || echo "No MSRV constraints found"Repository: InjectiveLabs/test-tube
Length of output: 92
🏁 Script executed:
# Search for any comments or documentation explaining the serde_json version choice
rg "serde_json|serde.json" -A 3 -B 3 --type md --type txtRepository: InjectiveLabs/test-tube
Length of output: 49
🌐 Web query:
serde_json 1.0.85 vs 1.0.140 changes breaking changes security advisories
💡 Result:
Summary: serde_json 1.0.85 → 1.0.140
Breaking changes
- No semver-breaking API changes are documented between these releases (they are both
1.0.xpatch releases). - The most common “practical breaking change” when upgrading is dependency-version compatibility:
serde_json 1.0.140requiresserde ^1.0.194(i.e.,>= 1.0.194, <2.0.0). If your workspace pinsserdeto an older exact version, Cargo can fail to resolve versions. [1][2]
Notable behavior / API changes since 1.0.85 (selected highlights)
- 1.0.85 (Aug 21, 2022):
Displayforserde_json::Numberchanged to match the representation produced by serialization (can affect string formatting / golden tests). [3] - 1.0.87: added
write_i128/write_u128hooks onserde_json::Formatter(new customization surface; additive). [3] - 1.0.89: fixed a case where invalid JSON could be accepted (large number with a decimal point but no digits after it). This is a correctness tightening and can make previously-accepted inputs start failing to parse. [3]
- 1.0.140 (Mar 3, 2025): release notes indicate documentation improvements. [4]
Security advisories
- No published GitHub Security Advisories are listed for
serde-rs/json(theserde_jsonrepo). [5] - RustSec’s JSON-related advisory in this area is for
serde-json-wasm, notserde_json: it addresses stack overflow / DoS via deeply nested JSON and is tracked as RUSTSEC-2024-0012 / CVE-2024-58264. [6]
Sources:
[1] https://deps.rs/crate/serde_json/1.0.140
[2] https://www.reddit.com/r/rust/comments/1j0zzhw (example of Cargo resolution failure due to serde_json requiring newer serde)
[3] https://rustrepo.com/repo/serde-rs-json-rust-json (release notes list including v1.0.85, v1.0.87, v1.0.89)
[4] https://github.com/serde-rs/json/releases (v1.0.140 notes)
[5] https://github.com/serde-rs/json/security
[6] https://rustsec.org/advisories/RUSTSEC-2024-0012.html
🏁 Script executed:
# Check for serde constraints in all Cargo.toml files
fd -t f "Cargo.toml" | xargs grep -n "serde" | grep -E "(version|=)" | head -30Repository: InjectiveLabs/test-tube
Length of output: 288
🏁 Script executed:
# Look for dependencies that might constrain serde version
rg "serde" --type toml -B 2 -A 2 | head -50Repository: InjectiveLabs/test-tube
Length of output: 1898
🏁 Script executed:
# Check if there are any comments or documentation about serde/serde_json versions
rg "1\.0\.144|1\.0\.85" packages/injective-test-tube/Repository: InjectiveLabs/test-tube
Length of output: 207
🏁 Script executed:
# Check other crates in the workspace to see their serde requirements
find . -name "Cargo.toml" -path "*/packages/*/Cargo.toml" -exec grep -H "serde" {} \;Repository: InjectiveLabs/test-tube
Length of output: 285
🏁 Script executed:
# Check serde requirements of all direct dependencies in injective-test-tube
cat packages/injective-test-tube/Cargo.toml | grep -A 50 "\[dependencies\]" | grep "="Repository: InjectiveLabs/test-tube
Length of output: 705
🏁 Script executed:
# Search for any serde version constraints in dependencies
rg "serde" packages/injective-test-tube/ -t toml -C 2Repository: InjectiveLabs/test-tube
Length of output: 550
🌐 Web query:
serde_json 1.0.140 serde version requirement 1.0.194 compatibility
💡 Result:
serde_json = 1.0.140 declares a dependency on serde with the requirement ^1.0.194. That means Cargo will accept any serde version >= 1.0.194 and < 2.0.0, including serde = 1.0.194 exactly. [1]
So serde_json 1.0.140 and serde 1.0.194 are compatible. [1]
Source: deps.rs shows serde_json 1.0.140 → serde ^1.0.194. [1]
[1] https://deps.rs/crate/serde_json/1.0.140
🌐 Web query:
cosmrs 0.22.0 serde requirement compatibility
💡 Result:
cosmrs 0.22.0 depends on:
serde = "1"withfeatures = ["serde_derive"]serde_json = "1"
So it’s compatible with any Serde 1.x release (i.e., >= 1.0.0, < 2.0.0). If your dependency graph forces serde 0.x or a hypothetical future serde 2.x, it won’t satisfy cosmrs 0.22.0’s requirement. [1]
Source: Cargo.toml for cosmrs 0.22.0 on docs.rs. [1]
References
[1] (docs.rs)
Citations:
🌐 Web query:
cosmwasm-std 3.0.2 serde requirement version
💡 Result:
cosmwasm-std = 3.0.2 depends on:
serde = 1.0.192(withdefault-features = false,features = ["alloc", "derive", "std"]) [1]
🏁 Script executed:
cat packages/test-tube/Cargo.toml | grep -A 50 "\[dependencies\]" | head -30Repository: InjectiveLabs/test-tube
Length of output: 487
Address the underlying serde version constraint instead of downgrading serde_json.
The serde_json downgrade to 1.0.85 is a symptom, not the root issue. The sibling package test-tube uses serde_json 1.0.140, but injective-test-tube cannot due to its explicit serde = "1.0.144" pin. Since serde_json 1.0.140 requires serde ≥ 1.0.194 and cosmwasm-std 3.0.2 requires serde ≥ 1.0.192, the serde version should be upgraded to at least 1.0.194 to align with both constraints and allow use of the newer serde_json. There are no security advisories or breaking changes between versions that would justify keeping 1.0.85—the constraint is purely a dependency version mismatch.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/injective-test-tube/Cargo.toml` around lines 19 - 20, The crate's
explicit serde pin (serde = "1.0.144") is forcing serde_json to be downgraded;
update the Cargo.toml for injective-test-tube to allow serde >= 1.0.194 (e.g.,
change the serde dependency from "1.0.144" to "1.0.194" or a compatible caret
range like ">=1.0.194" / "^1.0.194") and then restore or remove the hardcoded
serde_json = "1.0.85" so the resolver can select serde_json 1.0.140 (matching
test-tube) and satisfy cosmwasm-std 3.0.2's serde >=1.0.192 constraint.
|
|
||
| [dev-dependencies] | ||
| cw1-whitelist = "2.0.0" | ||
| cw1-whitelist = "1.1.2" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the Cargo.toml file and surrounding context
cat -n packages/injective-test-tube/Cargo.toml | head -40Repository: InjectiveLabs/test-tube
Length of output: 1381
🏁 Script executed:
# Search for cw1-whitelist usage in the codebase
rg "cw1_whitelist|cw1-whitelist" --type rust -iRepository: InjectiveLabs/test-tube
Length of output: 508
🏁 Script executed:
# Look for test files that might use this dependency
fd "test" packages/injective-test-tube --type f -x grep -l "cw1_whitelist\|cw1-whitelist" {} \;Repository: InjectiveLabs/test-tube
Length of output: 49
🌐 Web query:
cw1-whitelist 1.1.2 2.0.0 breaking changes Rust contract-whitelist
💡 Result:
From cw1-whitelist 1.1.2 → 2.0.0, the contract interface and storage layout appear unchanged (same InstantiateMsg, ExecuteMsg, QueryMsg, and same AdminList stored under "admin_list"), so there’s no obvious state migration needed for this contract itself. [1][2]
The breaking changes are primarily “ecosystem / dependency” breaks due to the CosmWasm 2.0 upgrade:
- CosmWasm / CW crates major bump:
cosmwasm-std,cosmwasm-schema,cw-storage-plus,cw-utils,cw2, andcw-multi-testmove from^1.xto^2.0.0. This is the main source of downstream breakage if your workspace is still on CosmWasm 1.x. [1][2] - Binary serialization helper rename: the contract switches from importing/using
to_binary(1.1.2) toto_json_binary(2.0.0). If you call helpers directly or mirror patterns in your own code, you must update imports/usage accordingly. [3][4] cw1dependency version alignment:cw1-whitelist2.0.0 depends oncw1 ^2.0.0-rc.0, so your dependency graph must be compatible with the CW v2 line. [1]
Sources:
[1] cw1-whitelist 2.0.0 docs.rs (dependencies/versions) (docs.rs)
[2] cw1-whitelist 1.1.2 docs.rs (dependencies/versions) (docs.rs)
[3] cw1-whitelist 2.0.0 contract.rs (uses to_json_binary) (docs.rs)
[4] cw1-whitelist 1.1.2 contract.rs (uses to_binary) (docs.rs)
Citations:
- 1: https://docs.rs/crate/cw1-whitelist/2.0.0
- 2: https://docs.rs/crate/cw1-whitelist/1.1.2
- 3: https://docs.rs/crate/cw1-whitelist/2.0.0/source/src/contract.rs
- 4: https://docs.rs/crate/cw1-whitelist/1.1.2/source/src/contract.rs
🏁 Script executed:
# Get more context around cw1_whitelist usage in app.rs
rg -B 5 -A 10 "cw1_whitelist" packages/injective-test-tube/src/runner/app.rsRepository: InjectiveLabs/test-tube
Length of output: 2118
🏁 Script executed:
# Check if there are any Cargo.lock or other version constraints
git ls-files | grep -i "cargo.lock\|Cargo.toml" | head -20Repository: InjectiveLabs/test-tube
Length of output: 158
🏁 Script executed:
# Look at the dependency tree or any version constraints that might explain the downgrade
cat packages/injective-test-tube/Cargo.toml | grep -A 20 "\[dev-dependencies\]"Repository: InjectiveLabs/test-tube
Length of output: 212
Revert cw1-whitelist to 2.0.0 for proper CosmWasm ecosystem alignment.
The project uses cosmwasm-std = "3.0.2" (CosmWasm 2.0+), but cw1-whitelist 1.1.2 targets CosmWasm 1.x. While the downgrade works for tests because only message types and the pre-built WASM binary are used (interface unchanged), it creates an unnecessary dependency ecosystem mismatch. Use cw1-whitelist 2.0.0 to align with the CosmWasm 2.0+ versions already in use.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/injective-test-tube/Cargo.toml` at line 26, Update the cw1-whitelist
dependency in Cargo.toml back to version 2.0.0 to align with the CosmWasm 2.x
ecosystem used by cosmwasm-std = "3.0.2"; locate the cw1-whitelist entry
(cw1-whitelist = "1.1.2") and change it to 2.0.0 so the crate versions are
consistent with CosmWasm 2.0+.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/test-tube/src/runner/app.rs`:
- Around line 339-344: The code currently converts gas_price.amount via
gas_price.amount.to_string().parse::<u128>().unwrap(), which can panic for
values > u128::MAX; change the calculation to perform arithmetic in a
big-integer type (e.g. Uint256 / TryFrom) or use try_into()/TryFrom to parse
gas_price.amount fallibly and propagate the error instead of unwrap; update the
block that constructs cosmrs::Coin (referencing gas_price.amount, gas_limit, and
Coin.amount) to compute the fee using Uint256 or a TryFrom conversion and
return/propagate an error on failure rather than calling unwrap.
| let amount = cosmrs::Coin { | ||
| denom: self.fee_denom.parse().unwrap(), | ||
| amount: (((gas_limit as f64) * (gas_price.amount.u128() as f64)).ceil() as u64) | ||
| amount: (((gas_limit as f64) | ||
| * (gas_price.amount.to_string().parse::<u128>().unwrap() as f64)) | ||
| .ceil() as u64) | ||
| .into(), |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's look at the exact code in the file and surrounding context
cat -n packages/test-tube/src/runner/app.rs | sed -n '330,350p'Repository: InjectiveLabs/test-tube
Length of output: 1122
🏁 Script executed:
# Check the Cargo.toml to see the cosmwasm-std version used
cat packages/test-tube/Cargo.toml | grep -A 2 -B 2 cosmwasm-stdRepository: InjectiveLabs/test-tube
Length of output: 428
🏁 Script executed:
# Also search for any other usages of gas_price or fee conversions in the codebase to understand the pattern
rg "gas_price" packages/test-tube/src/runner/app.rs -B 3 -A 3Repository: InjectiveLabs/test-tube
Length of output: 1407
🌐 Web query:
cosmwasm-std 3.0.2 Coin amount type definition
💡 Result:
In cosmwasm-std 3.0.2, the Coin type is defined as:
pub struct Coin {
pub denom: String,
pub amount: Uint256,
}So the amount field’s type is Uint256. [1]
Uint256 is a 256-bit unsigned integer type that uses strings for JSON encoding/decoding (to avoid precision loss in clients like JavaScript). [2]
Sources: [1] [2]
🌐 Web query:
cosmwasm-std Coin::amount type Uint256 Uint128 conversion
💡 Result:
In cosmwasm-std v3.x, Coin::amount is Uint256 (not Uint128), and Coin::new accepts anything Into<Uint256>. [1]
Uint128 → Uint256
Uint256 implements From<Uint128> and also provides a const helper:
use cosmwasm_std::{Uint128, Uint256};
let a128 = Uint128::new(123);
let a256: Uint256 = a128.into(); // or: Uint256::from(a128)
let a256b = Uint256::from_uint128(a128); // const-friendly[2]
Uint256 → Uint128 (fallible)
Converting back can overflow, so it’s TryFrom:
use cosmwasm_std::{Uint128, Uint256};
let a256 = Uint256::new(123);
let a128: Uint128 = a256.try_into()?; // Result<Uint128, ConversionOverflowError>[3]
If you’re seeing Coin { amount: Uint128, ... }
That’s from older CosmWasm/chain docs (pre-v3), where Coin.amount was Uint128 in examples. [4] In that setup, you can still do:
let amt256: Uint256 = coin.amount.into();Sources: [1] [2] [3] [4]
Use fallible conversion for gas_price.amount to avoid panic.
At lines 341–343, gas_price.amount.to_string().parse::<u128>().unwrap() will panic if the amount exceeds u128::MAX. Since Coin.amount in cosmwasm-std 3.0.2 is Uint256, which can hold values larger than u128, this conversion is unsafe. Use try_into() or TryFrom instead and propagate the error, or perform the calculation in Uint256 and convert only the final result.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/test-tube/src/runner/app.rs` around lines 339 - 344, The code
currently converts gas_price.amount via
gas_price.amount.to_string().parse::<u128>().unwrap(), which can panic for
values > u128::MAX; change the calculation to perform arithmetic in a
big-integer type (e.g. Uint256 / TryFrom) or use try_into()/TryFrom to parse
gas_price.amount fallibly and propagate the error instead of unwrap; update the
block that constructs cosmrs::Coin (referencing gas_price.amount, gas_limit, and
Coin.amount) to compute the fee using Uint256 or a TryFrom conversion and
return/propagate an error on failure rather than calling unwrap.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
2 participants
Summary by CodeRabbit
New Features
Changed
Tests