Skip to content
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

Closed
1 task done
silasdavis opened this issue Dec 28, 2023 · 3 comments · Fixed by #21006
Closed
1 task done

[Bug]: NewIntegrationApp does not write default genesis to state #18910

silasdavis opened this issue Dec 28, 2023 · 3 comments · Fixed by #21006
Assignees
Labels

Comments

@silasdavis
Copy link

silasdavis commented Dec 28, 2023

Is there an existing issue for this?

  • I have searched the existing issues

What happened?

In trying to use the NewIntegrationApp helper to test a module I noticed that the state written by InitChain sourced from DefaultGenesis 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#L119

See 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 with MaxMemoCharacters 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 the Params struct, indicating that the InitChain is not writing the initial genesis state to the underlying IAVL tree.

@silasdavis
Copy link
Author

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.

@facundomedica facundomedica self-assigned this Dec 29, 2023
@facundomedica
Copy link
Member

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.
I'll need to do some more digging before knowing how to fix it.

@Thomas-Kim
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants