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

feat(rollback): enable rollback support #656

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

srene
Copy link
Contributor

@srene srene commented Jan 2, 2025

Description


Closes #623

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow-up issues.

PR review checkboxes:

I have...

  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Targeted PR against the correct branch
  • included the correct type prefix in the PR title
  • Linked to the GitHub issue with discussion and accepted design
  • Targets only one GitHub issue
  • Wrote unit and integration tests
  • Wrote relevant migration scripts if necessary
  • All CI checks have passed
  • Added relevant godoc comments
  • Add an issue in the e2e-tests repo if necessary

SDK Checklist

  • Import/Export Genesis
  • Registered Invariants
  • Registered Events
  • Updated openapi.yaml
  • No usage of go map
  • No usage of time.Now()
  • Used fixed point arithmetic and not float arithmetic
  • Avoid panicking in Begin/End block as much as possible
  • No unexpected math Overflow
  • Used sendCoin and not SendCoins
  • Out-of-block compute is bounded
  • No serialized ID at the end of store keys
  • UInt to byte conversion should use BigEndian

Full security checklist here


For Reviewer:

  • Confirmed the correct type prefix in the PR title
  • Reviewers assigned
  • Confirmed all author checklist items have been addressed

After reviewer approval:

  • In case the PR targets the main branch, PR should not be squash merge in order to keep meaningful git history.
  • In case the PR targets a release branch, PR must be rebased.

@srene srene self-assigned this Jan 2, 2025
@srene srene requested a review from a team as a code owner January 2, 2025 14:48
@danwt
Copy link
Contributor

danwt commented Jan 3, 2025

dymensionxyz/dymint#1300

Copy link
Contributor

@danwt danwt left a comment

Choose a reason for hiding this comment

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

Seems to do the opposite of what the issue says


I don't think rollback is going to work properly anyway, in general, because UpdateStateAfterCommit only changes ConsensusParams or RollappParams if there is some response from the block.

So say you have heights 1,2,3

On height 2 the consensus params and rollapp params are changed

Then rollback from 3 -> 1 will not have the right values in state afterwards

Comment on lines 82 to 98
fmt.Printf("Pruning store from height %d to %d\n", heightInt+1, blockManager.State.Height()+1)

pruned, err := blockManager.Store.PruneHeights(uint64(heightInt+1), blockManager.State.Height()+1, ctx.Logger)
if err != nil {
return fmt.Errorf("pruning: %w", err)
}

_, err = blockManager.Store.LoadBlock(blockManager.State.Height() + 2)
if err == nil {
extraPruned, err := blockManager.Store.PruneHeights(blockManager.State.Height()+1, blockManager.State.Height()+2, ctx.Logger)
if err != nil {
return fmt.Errorf("pruning: %w", err)
}
pruned += extraPruned
}

fmt.Println("Pruned blocks:", pruned)
Copy link
Contributor

Choose a reason for hiding this comment

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

can dry it a lot if you check the state.height+2 first, and then do PruneHeights once (with possible+1)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@danwt danwt self-requested a review January 3, 2025 16:39
@omritoptix omritoptix linked an issue Jan 5, 2025 that may be closed by this pull request
@@ -74,19 +74,49 @@ func RollbackCmd(appCreator types.AppCreator) *cobra.Command {
return fmt.Errorf("app rollback to specific height: %w", err)
}

fmt.Printf("RollApp state moved back to height %d successfully.\n", heightInt)

skipStorePruning := ctx.Viper.GetBool(flags.FlagLogLevel)
Copy link
Collaborator

Choose a reason for hiding this comment

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

wrong flag

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed


skipStorePruning := ctx.Viper.GetBool(flags.FlagLogLevel)

if !skipStorePruning {
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
if !skipStorePruning {
if skipStorePruning {
return
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

return fmt.Errorf("pruning: %w", err)
}

_, err = blockManager.Store.LoadBlock(blockManager.State.Height() + 2)
Copy link
Collaborator

Choose a reason for hiding this comment

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

not sure why it's needed
dymint store shouldn't be accessed while rollback in progress

Copy link
Contributor Author

Choose a reason for hiding this comment

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

to check if an extra block its been produced but not applied yet to remove it

@srene
Copy link
Contributor Author

srene commented Jan 8, 2025

Seems to do the opposite of what the issue says

I don't think rollback is going to work properly anyway, in general, because UpdateStateAfterCommit only changes ConsensusParams or RollappParams if there is some response from the block.

So say you have heights 1,2,3

On height 2 the consensus params and rollapp params are changed

Then rollback from 3 -> 1 will not have the right values in state afterwards

dymint stores all block responses and every response includes consensus and rollapp params for height. UpdateStateFromApp replaces dymint state cons and rollapp params from the responses of rollback height.

@srene srene requested a review from mtsitrin January 8, 2025 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add rollback support Support the ability to rollback to specific state
3 participants