feat: expose nodeDB's DeleteVersionsFrom method #952
Conversation
WalkthroughThis update introduces the Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant MutableTree
Client->>MutableTree: DeleteVersionsFrom(version int64)
MutableTree-->>Client: Success/Error Response
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
|
@pirtleshell thanks for the contribution, it is used in |
|
@cool-develope sure thing. rollback caseFirst, suppose you are adding a new sdk module during an upgrade. Suppose there is a bug in that module addition such that the root hash of the new module is non-deterministic & results in an app hash mismatch when the upgrade is run in a network. The goal is to roll back the bad version & re-run the upgrade with a patched binary. The SDK's This occurs when AFAIK, to get around this and successfully roll back, you have two options:
However, either of those options still leaves the upgrade version of the added module's store on disk. When the upgrade is re-attemtped, the new data will not be committed because of the version that already exists on disk. The relevant sdk code is here: The code is necessary to recover from interruptions, but means that new data is never committed & written to disk for the patched binary's upgrade block. If it were to manage calling commit, the IAVL Commit() method would likely error here due to mismatched data (the patched binary's version will differ from the bad one that was committed in the failed upgrade). To truly rollback & re-run the upgrade, the data must be removed from disk. sharding caseLess important with the awesome space-saving y'all have been doing with iavl v1 & v2, but I recognize that much of what I describe about Happy to make any changes, explain anything further, or open an issue/discussion. |
makes sense, thanks for the detail explanation! |
|
@pirtleshell do you think we also need to update cosmos-sdk for the upgrade rollback case? |
yes, i wanted to get this into iavl first but i do have a rough implementation of an update to the rollback command that fully removes the KVStore on disk for listed modules. i linked it in the issue i opened on cosmos/cosmos-sdk#20472 probably needs cleanup but it is here: Kava-Labs/cosmos-sdk#546 thinking through it right now, the cosmos-sdk versions that use iavl v0.20 can & probably should use |
pirtleshell
force-pushed
the
pirtleshell/delete-versions-from
branch
from
ffd5362
to
7908810
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
CHANGELOG.md (1)
Line range hint
167-167: Consider adding a comma after "v1.17" for better readability.- Use go v1.17 For previous changelogs visit: <https://github.com/cosmos/iavl/blob/v0.18.0/CHANGELOG.md> + Use go v1.17, For previous changelogs visit: <https://github.com/cosmos/iavl/blob/v0.18.0/CHANGELOG.md>
|
@cool-develope anything else needed for this PR? i think i may have confused the CI by rebasing on master to fix CHANGELOG conflict. 🙂 |
|
bump @cool-develope @tac0turtle |
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- mutable_tree.go (1 hunks)
Additional comments not posted (1)
mutable_tree.go (1)
872-880: New methodDeleteVersionsFromadded toMutableTree.The implementation of
DeleteVersionsFrommethod is straightforward and matches the intended functionality described in the PR. This method complements the existingDeleteVersionsToby providing a way to delete versions from a specified version upwards. It's important to ensure that this method does not introduce any regressions or affect the existing functionality adversely.
- Please ensure that there are sufficient tests covering scenarios where versions just above and just below the
fromVersionare correctly handled.- Additionally, verify that no data corruption occurs when this method is used in conjunction with other tree operations.
Verification successful
Test coverage for
DeleteVersionsFrommethod is adequate.The
TestDeleteVersionsFromfunction inmutable_tree_test.goverifies that versions below the specifiedfromVersionremain unaffected while versions above are correctly deleted. This ensures that theDeleteVersionsFrommethod works as intended without causing data corruption or regression.
- The test sets up a
MutableTree, saves multiple versions, and deletes versions from a specified version upwards.- It then checks for the existence of versions below the
fromVersionand confirms the non-existence of versions above it.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that `DeleteVersionsFrom` does not affect versions below `fromVersion`. # Test: Search for test cases for `DeleteVersionsFrom`. rg --type go "TestDeleteVersionsFrom" mutable_tree_test.goLength of output: 102
Script:
#!/bin/bash # Extract the TestDeleteVersionsFrom function code from mutable_tree_test.go for review. ast-grep --lang go --pattern $'func TestDeleteVersionsFrom(t *testing.T) { $$$ }' mutable_tree_test.goLength of output: 1598
|
bump @cool-develope @tac0turtle is anything further needed for this to be included? |
|
@pirtleshell could merge main into your branch then we can merge it |
There was a problem hiding this comment.
Actionable comments posted: 1
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (3)
- CHANGELOG.md (1 hunks)
- mutable_tree.go (1 hunks)
- mutable_tree_test.go (2 hunks)
Additional comments not posted (4)
CHANGELOG.md (1)
7-7: Validate the changelog entries for new APIs.The entries for the new APIs
DeleteVersionsFromandGetLatestVersionare correctly documented under the "Improvements" section. This aligns with the changes made in the PR.mutable_tree.go (1)
877-885: Review the implementation ofDeleteVersionsFrom.The method
DeleteVersionsFromis correctly implemented to queue the deletion of versions from a specified version upwards. The method defers the execution and does not block theSaveVersion()call, which is in line with the described functionality in the PR.mutable_tree_test.go (2)
Line range hint
115-134: Review ofTestDeleteVersionsToFunctionThis function tests the deletion of versions up to a specified version. The logic appears correct, and the use of
requireensures that the test will halt on failure, which is appropriate for unit tests. However, the function name has been changed from a more generalTestDeleteto a more specificTestDeleteVersionsTo. This is a positive change as it clarifies the intent of the test.
- Correctness: The test correctly sets up a tree, saves versions, and then attempts to delete versions up to a specified point. It then checks if the versions have been deleted as expected.
- Performance: The test is efficient in terms of operations performed.
- Best Practices: Using
requirefor immediate test failure upon a condition failure is a good practice in unit tests.
136-161: Review ofTestDeleteVersionsFromFunctionThis newly added function tests the deletion of versions from a specified version onwards. The structure and logic of the test are consistent with the existing testing patterns in the file.
- Correctness: The function correctly tests the new
DeleteVersionsFrommethod by setting a tree, saving versions, and then deleting from a specified version onwards. It checks the existence of versions before and after the specified version to ensure proper deletion.- Error Handling: Proper error handling is used with
require.NoErrorto ensure that any error in the setup or deletion process halts the test.- Performance: The operations are minimal and focused, which is suitable for unit testing.
- Best Practices: The test is well-structured and follows good practices in testing expected and edge cases.
| ## Unreleased | ||
|
|
There was a problem hiding this comment.
Ensure proper formatting in the changelog.
It's good practice to maintain consistent formatting in changelog entries. Ensure that there are blank lines surrounding major sections for better readability.
## Unreleased
+Committable suggestion was skipped due to low confidence.
|
bumping again, hoping to get this merged @tac0turtle @cool-develope 🙏 |
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (2)
- mutable_tree.go (1 hunks)
- mutable_tree_test.go (2 hunks)
Additional comments not posted (3)
mutable_tree.go (1)
876-884: LGTM! But verify the function usage in the codebase.The code changes are approved.
However, ensure that all function calls to
DeleteVersionsFromare correctly implemented.Verification successful
Function usage is correctly implemented and tested.
The function
DeleteVersionsFromis used and tested appropriately in the codebase.
mutable_tree_test.go: The function is tested to ensure it works as expected.nodedb_test.go: The function is also tested here to ensure no deadlocks occur.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `DeleteVersionsFrom` match the new signature. # Test: Search for the function usage. Expect: Only occurances of the new signature. rg --type go -A 5 $'DeleteVersionsFrom'Length of output: 2584
mutable_tree_test.go (2)
Line range hint
114-134:
LGTM!The code changes are approved.
135-160: LGTM!The code changes are approved.
DeleteVersionsFromis the counterpart toDeleteVersionsTo. It writes deletions of aMutableTreeto disk for all versions >= the providedfromVersion.It exposes the method of the same name from the underlying
nodeDB.This method is useful for things like:
Please let me know if this should first be proposed as a Feature Request via the repo issues.
Summary by CodeRabbit
New Features
DeleteVersionsFromAPI.Tests