-
Notifications
You must be signed in to change notification settings - Fork 545
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
FIX: Ignite Produces Forks #4141
Comments
Maybe upgrade handler is incomplete in that case; to check: |
Doesn't help with forks (tested) |
Also fixed the wasm path but still forks |
I've tested the changes proposed here (cosmos/cosmos-sdk#18521) and also it forks |
FYI I've tested to make a no-op upgrade and it doesn't forks; later apply a new upgrade with wasm's adding and it forked |
@RaulBernal, check the wasm implementation from the ignite wasm app |
|
@RaulBernal can you share your chain config TOML? If you restart your chain with Ignite using the |
I've checked my config.toml in devchain and it hasn't had the Wasm config lines. [wasm]
# Smart query gas limit is the max gas to be used in a smart query contract call
query_gas_limit = 3000000
# in-memory cache for Wasm contracts. Set to 0 to disable.
# The value is in MiB not bytes
memory_cache_size = 100
# Simulation gas limit is the max gas to be used in a tx simulation call.
# When not set the consensus max block gas is used instead
# simulation_gas_limit = and this to app.toml: [wasm]
# Smart query gas limit is the max gas to be used in a smart query contract call
query_gas_limit = 3000000 I restored a backup and performed new upgrades, from v0.47 to v0.50 and add the Wasm module at v0.50 and it forks again :( |
@RaulBernal the issue #4140 was solved in the |
@RaulBernal, I can't figure out what is missing for the upgrade works. Try to use the same upgrade handlers from |
@Pantani , big part of that upgrade file you pointed me is related to v47>v50 upgrade and wasmvm v1>v2. I think we need to review why (which part) forks. cc: @julienrbrt |
Latest test in ignite/apps#123 & others made in private by Discord show us that the WASM implementation is not the focus of the problem. |
Last week I tried an upgrade from BC fork (Ignite) in v0.47 to v0.50 SimApp (app_v2) and it works with no AppHashes. |
Following our call, we haven't be able to reproduce this issue, and potential issues with optimistic execution or peers aren't tied to Ignite. FWIW, we've disabled optimistic execution in v28.5.2, as it was causing issues to more than ignite users. |
Describe the bug
After include the WASM module using this official guide and stop/start nodes again, the nodes get Apphashes and fork the chain.
We have tested to:
wasm
module.In both cases, when one of the two validators stops & starts it get the APPHash.
To reproduce
Steps to reproduce the behavior:
This is the log when one of the nodes stops&starts after the successful upgrade of
wasm
module (doesn't matters if the upgrade happens in the v0.47>v0.50 process or in a separate v0.50>v0.50 module addsWhat version are you using?
v0.28.3
Source code tested
For reference, this is the last code used to make a test with v0.50.5 to v0.50.5 adding the
wasm
module that produce forks (not in the upgrade time, but after)Ignite add wasm
): RaulBernal/bcna_v4cosmwasm@ec15912The text was updated successfully, but these errors were encountered: