refactor: address snapshot/pruning refactor comments upstream#184
refactor: address snapshot/pruning refactor comments upstream#184alexanderbez merged 46 commits intoosmosis-mainfrom
Conversation
snapshots/manager.go
Outdated
There was a problem hiding this comment.
should this be <= 0 (I asked based on the error message)?
There was a problem hiding this comment.
Yes, you are right. I will get that changed
pruning/manager.go
Outdated
There was a problem hiding this comment.
| // reuse previously allocated memory. | |
| // reuse previously allocated memory |
pruning/manager.go
Outdated
There was a problem hiding this comment.
This this really necessary? How would this change?
If we must do this, let's reference (and create) an issue. I'd like to avoid "naked" TODOs.
There was a problem hiding this comment.
No, you are right. It's not really necessary unless we start reusing this functionality with other types. I removed the comment
There was a problem hiding this comment.
ugh, I've been switching frequently between this repo and the SDK repo, likely merged by accident
will ve removed
|
@alexanderbez thanks for the review. Will get back to your comments. I might have to update this PR with more changes from the comments in the upstream so marking this as a draft for now |
270bdd1 to
5b2697d
Compare
e684bda to
95e8071
Compare
|
All comments are now addressed. I backported all changes from the upstream up until: #187 I will do everything including and after it in a separate PR to limit the scope here |
alexanderbez
left a comment
There was a problem hiding this comment.
Reviewing both of these PRs in the SDK and our fork is not tenable IMO. Can we wait till the SDK one is merged or vice versa? I left a bunch of comments in the core repo.
pruning/manager.go
Outdated
There was a problem hiding this comment.
This is a string. It should not start with err
Sounds good. I agree. Let's wait until the core is accepted |
4fcdd02 to
cf03c8e
Compare
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
5c12960 to
6d2ac52
Compare
|
Hi @alexanderbez This is a backport of all commits in cosmos#11496 Can we merge this? |
Description
Addressing functional and security comments from review upstream:
cosmos#11496
Testing
Tested this on Osmosis v7.x: #206
mainis unstableprune-everythingthe interval and keep-recent are both 10Following the Logs
If we specify a small
snapshot-interval(such as 100) and snapshots overlap, the new requests to snapshot will be skipped if there is one that is already in progress. Therefore, I split the snapshot height tests into 2 cases:Snapshot Heights - Snapshot Performed
Verified that it works as expected by exposing some debug logs:
When we would normally prune height
4080000(at4080010), the snapshot height does not show up anymore because it is kept until after a snapshot is done:Eventually we see the following log message signifying that a snapshot height was pruned away:
Snapshot Heights - Skipped
Snapshot heights that overlap with an already in progress snapshot are skipped and pruned almost immediately:
4080100is out of order because it was added to the list in a separate goroutine after we checked for an in progress snapshot.Regular Heights
For heights that are not multiples of snapshot-interval are removed right away according to the pruning strategy:
Querying
I attempted to query epochs at a specific height. As soon as the queried height went beyond keep-recent, I would get an error. Ths indicates that pruning functions correctly.
Flow of events:
10:03PM INF pruning heights heights=[4080130,4080131,4080132,4080133,4080134,4080135,4080136,4080137,4080138,4080139]in the logs