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

fix: remove stores from renamed/deleted store upgrades #9409

Merged
merged 18 commits into from
Jul 12, 2021

Conversation

technicallyty
Copy link
Contributor

@technicallyty technicallyty commented May 27, 2021

Description

  • stores that were renamed are now properly deleted
  • deleted/renamed and renamed stores are no longer added to CommitInfo
  • deleted/renamed stores are now properly removed from rootmulti store's memory

ref: #7991
closes: N/A


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@codecov
Copy link

codecov bot commented May 27, 2021

Codecov Report

Merging #9409 (21b451b) into master (0027111) will increase coverage by 24.96%.
The diff coverage is 62.97%.

❗ Current head 21b451b differs from pull request most recent head 8f44ec5. Consider uploading reports for the commit 8f44ec5 to get more accurate results
Impacted file tree graph

@@             Coverage Diff             @@
##           master    #9409       +/-   ##
===========================================
+ Coverage   35.48%   60.44%   +24.96%     
===========================================
  Files         332      590      +258     
  Lines       32620    37253     +4633     
===========================================
+ Hits        11575    22518    +10943     
+ Misses      19819    12754     -7065     
- Partials     1226     1981      +755     
Impacted Files Coverage Δ
client/keys/types.go 100.00% <ø> (+100.00%) ⬆️
client/keys/utils.go 42.85% <ø> (+2.50%) ⬆️
client/query.go 16.98% <ø> (ø)
client/rpc/block.go 10.00% <ø> (ø)
client/rpc/routes.go 100.00% <ø> (ø)
client/rpc/status.go 47.72% <ø> (ø)
client/rpc/validators.go 0.00% <ø> (ø)
client/test_helpers.go 0.00% <ø> (ø)
client/tx/factory.go 28.20% <ø> (ø)
client/tx/legacy.go 68.42% <ø> (ø)
... and 701 more

@technicallyty technicallyty marked this pull request as ready for review June 15, 2021 22:32
@clevinson
Copy link
Contributor

clevinson commented Jun 15, 2021

@robert-zaremba @aaronc can you of you have a look at this and give an ack if all looks good?

Copy link
Member

@tac0turtle tac0turtle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK.

For upgrades, would we want to keep renamed stores around and route to the old module if state is still present on the node for it?

Copy link
Collaborator

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm missing a context here.

  • What problem are we solving? Fix upgrate store loader #7991 doesn't provide a clear context either.
  • Why do we need to remember deleted stores?
  • What should happen if someone wants to save a data to a deleted store? I suggest we should fail (return error). We are missing a test for that.
  • What should happen when we restart an app?
  • Documentation is missing.


rs.lastCommitInfo = commitStores(version, rs.stores)
// remove remnants of removed stores
for sk := range rs.removalMap {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for sk := range rs.removalMap {
for key := range rs.removalMap {

@technicallyty
Copy link
Contributor Author

re: @robert-zaremba

Renamed stores were not being removed from storage. Since the original store from a rename was never added to the newStore map, once a commit happened - the commit store would just assume no changes were made to that store, so it would leave it as is.

  • Why do we need to remember deleted stores?

The stores that need to be deleted are only held temporarily in the removalMap until the next commit. Once a commit happens, the map is used to clear the root store of the stores in the map (ones that need to be deleted). Without that, renamed and deleted stores persist to memory, and renamed stores persist to storage, rather than being cleared.

  • What should happen if someone wants to save a data to a deleted store? I suggest we should fail (return error). We are missing a test for that.

Wouldn't you first have to acquire the key? I believe we already have errors to handle that situation, but i can look into fleshing out a more direct test for this situation though

  • What should happen when we restart an app?

not sure - do you see any issues that could arise from this?

  • Documentation is missing.

i can add some lines to cosmos-sdk/store readme

@technicallyty
Copy link
Contributor Author

re: @marbar3778

For upgrades, would we want to keep renamed stores around and route to the old module if state is still present on the node for it?

hmm could you explain this situation more? i'd assumed a rename with new module would be more of a hard fork situation

@tac0turtle
Copy link
Member

hmm could you explain this situation more? i'd assumed a rename with new module would be more of a hard fork situation

oh, I was thinking in the case of rolling upgrades. In the case of a hard fork I don't think this would matter cause migration scripts would handle it.

@technicallyty
Copy link
Contributor Author

oh, I was thinking in the case of rolling upgrades. In the case of a hard fork I don't think this would matter cause migration scripts would handle it.

ahh okay gotcha. are there situations where devs would inject StoreUpgrades outside of a migration script? maybe i'm missing the other use cases. my first thought here was to just add docs for devs to not run store upgrades outside a migration script.

@anilcse
Copy link
Collaborator

anilcse commented Jun 17, 2021

hmm could you explain this situation more? i'd assumed a rename with new module would be more of a hard fork situation

oh, I was thinking in the case of rolling upgrades. In the case of a hard fork I don't think this would matter cause migration scripts would handle it.

iirc on renaming a store, all the data is moved/copied over to the new store.

Copy link
Collaborator

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

@technicallyty technicallyty added the A:automerge Automatically merge PR once all prerequisites pass. label Jul 12, 2021
@mergify mergify bot merged commit d4d25f5 into master Jul 12, 2021
@mergify mergify bot deleted the ty/na-store_loader branch July 12, 2021 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass. C:x/upgrade
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants