-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Bug]: NewIntegrationApp does not write default genesis to state #18910
Comments
It would be great to know a if there is an obvious workaround for writing the state written into the keeper during initgenesis down into the IAVL state. |
Hey @silasdavis, it does look like a bug in the integration app. Seems like the issue here is how we handle contexts, as we pass in one context that doesn't really get used to write the data, and then we use another ctx to read the data. In the full test it works because we use the same context for running the MsgUpdateParams and for getting the params. |
Any blockers/ETA on fixing this? For my use case I fixed it by changing SetInitChainer to use sdkCtx in NewIntegrationApp, though I am not sure how it affects any other projects/tests. |
Is there an existing issue for this?
What happened?
In trying to use the
NewIntegrationApp
helper to test a module I noticed that the state written byInitChain
sourced fromDefaultGenesis
is not written to state.Cosmos SDK Version
main
How to reproduce?
To reproduce, run a modified
Example_oneModule
from https://github.com/cosmos/cosmos-sdk/blob/main/tests/integration/example/example_test.go#L119See this PR/commit for a minimal repro:
silasdavis#1
In that commit I have removed the part of the test that calls
RunMsg
to set the the params withMaxMemoCharacters
changed to 1000.I would expect to see the params take their default values.
Instead of observing params that take on the values set by
DefaultGenesis
you see that the params take on the zero value of theParams
struct, indicating that theInitChain
is not writing the initial genesis state to the underlying IAVL tree.The text was updated successfully, but these errors were encountered: