-
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
Bank Metadata store key format changed between v0.45 and v0.46 #13797
Comments
just discovered this PR #12028 that has migration logic for staking module. Would protocol normally be to add something like this for bank module when KV store was changed? |
The migration for key format change is included in the SDK, here: I think you need to call your @okwme if you have a gaia branch with this error, I can try to help there |
Thank you @AmauryM ! you're right that there is in fact a migration for bank that I missed somehow. You are also correct that we were attempting to call However after digging a bit deeper I believe that the bug DOES in fact exist despite the fact that it shouldn't have been visible from the current configuration (WHAT ARE THE CHANCES ACTUALLY??). After re-ordering the upgrade handler so that the migration occurred before we attempted to retrieve from the newly migrated store, it still fails with the same error! When iterating over the keys and value that are in the store, instead of I opened a PR with a fix: It's very unlikely that there would be 2 bugs that resulted in the same error happening simultaneously. But does that seem like the correct assessment to you? I'm working off of this branch https://github.com/cosmos/gaia/tree/okwme/test-upgrade-debug. To see the bug in action do the following steps:
|
Summary of Bug
We ran into a bug in gaia's upgrade handler related to the bank module and coin metadata. Basically we were getting validate genesis errors because the coin metadata was missing
Name
andSymbol
from theMetadata
. We decided to add them to the bank keeper like this:however we kept getting the error
atom denom not found
.The
GetDenomMetaData
should take theBase
denom string (uatom
) in this case and retrieve it using the bank keeper as follows:As you can see here the
store
is created usingtypes.DenomMetadataPrefix
and thendenom
is used as the key to retrieve the metadata. HOWEVER, this is not how the bank keeper originally stored this metadata in v0.45 of the Cosmos SDK. If we jump intoSetDenomMetadata
of the bank keeper of Cosmos SDK v0.45 we will see a different schema for storing the Metadata:Here we can see that the
store
is created using a different version of thetypes.DenomMetadataKey
, one that takesBase
as a parameter and subsequently appends with theBase
string:As opposed to Cosmos SDK v0.46.x where there is no use of
DenomMetadataKey
.TLDR:
Bank module changed the format for the key when storing coin metadata, so without an explicit migration between versions the application was unable to properly retrieve metadata with the old key after an upgrade from v0.45.x to v0.46.x.
Open Question:
We can modify and replace the store used in Gaia v8 with Cosmos SDK v0.46.x so that this is not an issue. But is this the correct way to address the problem? Do modules have their own KV migrations for situations like this or is it the responsibility of the app developer to notice changes like this and ensure upgrade logic is written in app.go to ensure continuity? Are there other apps this could impact or other ways to ensure that other modules haven't befallen a similar fate?
There was another recent issue in gaia that was moved to Cosmos SDK and then moved back to gaia because it was pointed out that it is the responsibility of the application to ensure data integrity. Is this an other instance of such an event and if so how do we make sure that application developers are aware of this kind of breaking change?
I see that the item was included under State Machine Breaking as follows:
The other state breaking changes seem to be built with backwards compatibility in mind. Would this have been addressed differently if this outcome had been considered? Should we just try to ensure a message that has an extra emphasis on ensuring your KV store is migrated to the new format during an upgrade? I'm not familiar enough with module development cycles to know where this could have been improved but would like to use it as an example so we can make an improvement, either on the side of app developer due diligence and change log review, or on the sdk side if there was some way to implement this change that wouldn't have resulted in a broken module during an upgrade.
Version
Steps to Reproduce
The text was updated successfully, but these errors were encountered: