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

refactor: remove unnecessary decrement when fast forwarding upgrade sequence #5231

Merged

Conversation

ThanhNhann
Copy link
Contributor

@ThanhNhann ThanhNhann commented Nov 29, 2023

Description

closes: #5218
closes: #5299


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 and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/).
  • Added relevant godoc comments.
  • Provide a commit message to be used for the changelog entry in the PR description for review.
  • Re-reviewed Files changed in the Github PR explorer.
  • Review Codecov Report in the comment section below once CI passes.

// NOTE: OnChanUpgradeInit will not be executed by the application
upgrade, err = k.ChanUpgradeInit(ctx, portID, channelID, proposedUpgradeFields)
if err != nil {
return types.Upgrade{}, errorsmod.Wrap(err, "failed to initialize upgrade")
}

// if the counterparty sequence is greater than the current sequence, we fast-forward to the counterparty sequence.
if counterpartyUpgradeSequence > channel.UpgradeSequence {
k.SetChannel(ctx, portID, channelID, channel)
Copy link
Contributor

Choose a reason for hiding this comment

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

i believe we still need to fastforward to the counterparty sequence, in case of the sequence being very much out of sync (timeouts).

Copy link
Contributor Author

@ThanhNhann ThanhNhann Dec 1, 2023

Choose a reason for hiding this comment

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

What do you think about this @chatton ?

Copy link
Contributor

@crodriguezvega crodriguezvega Dec 2, 2023

Choose a reason for hiding this comment

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

@charleenfei is right and I think you need to fast forward to the counterparty sequence before SetChannel. I think the reason the tests are passing at the moment is because we are missing a check to make sure that the upgrade sequences of both channel ends are in sync after ChannelUpgradeTry succeeds. If you add after this line a check like this suite.Require().Equal(path.EndpointA.GetChannel().UpgradeSequence, path.EndpointB.GetChannel().UpgradeSequence) you will see that this test will fail.

But I am thinking that probably we still need to do channel.UpgradeSequence = counterpartyUpgradeSequence - 1 anyway, because channel.UpgradeSequence is actually incremented in WriteUpgradeInitChannel below... Unless we move this code after WriteUpgradeInitChannel, I think.

Copy link
Contributor Author

@ThanhNhann ThanhNhann Dec 7, 2023

Choose a reason for hiding this comment

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

I re-added channel.UpgradeSequence = counterpartyUpgradeSequence - 1

Copy link
Contributor

Choose a reason for hiding this comment

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

Thank you, @ThanhNhann. To be honest, I don't know what would be best now: either leave the code where it was before or move it after WriteUpgradeInitChannel and then we probably don't need to do channel.UpgradeSequence = counterpartyUpgradeSequence - 1 and we can do just channel.UpgradeSequence = counterpartyUpgradeSequence. @damiannolan any thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

fixed

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @colin-axner

@codecov-commenter
Copy link

codecov-commenter commented Dec 12, 2023

Codecov Report

Merging #5231 (3497c9f) into 04-channel-upgrades (0323942) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

Impacted file tree graph

@@                 Coverage Diff                  @@
##           04-channel-upgrades    #5231   +/-   ##
====================================================
  Coverage                80.39%   80.39%           
====================================================
  Files                      197      197           
  Lines                    14984    14985    +1     
====================================================
+ Hits                     12046    12047    +1     
  Misses                    2474     2474           
  Partials                   464      464           
Files Coverage Δ
modules/core/04-channel/keeper/upgrade.go 91.58% <100.00%> (+0.01%) ⬆️

@crodriguezvega crodriguezvega added the channel-upgradability Channel upgradability feature label Dec 13, 2023
@colin-axner colin-axner changed the title Update ChanUpgradeTry function refactor: remove unnecessary decrement when fast forwarding upgrade sequence Dec 13, 2023
Copy link
Contributor

@colin-axner colin-axner left a comment

Choose a reason for hiding this comment

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

Thanks @ThanhNhann!

@colin-axner colin-axner merged commit baa0318 into cosmos:04-channel-upgrades Dec 13, 2023
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
04-channel channel-upgradability Channel upgradability feature core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants