Skip to content

consensus: fix round number when handling RoundStepNewRound timeout#9252

Merged
cmwaters merged 2 commits intotendermint:mainfrom
fatcat22:fix/from-main-round-of-newround-timeout
Aug 18, 2022
Merged

consensus: fix round number when handling RoundStepNewRound timeout#9252
cmwaters merged 2 commits intotendermint:mainfrom
fatcat22:fix/from-main-round-of-newround-timeout

Conversation

@fatcat22
Copy link
Contributor

Closes #9229


PR checklist

  • Tests written/updated, or no tests needed
  • CHANGELOG_PENDING.md updated, or no changelog entry needed
  • Updated relevant documentation (docs/) and code comments, or no
    documentation updates needed

Copy link
Contributor

@cmwaters cmwaters left a comment

Choose a reason for hiding this comment

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

LGTM

@milosevic any idea why it was like this in the first place?

@cason
Copy link

cason commented Aug 16, 2022

Is there a test case that reveals this problem?

@cason
Copy link

cason commented Aug 16, 2022

I can double-check, but this timeout is scheduled when the node enters a height. This means that when it is triggered, the round to start is always 0.

@cason
Copy link

cason commented Aug 16, 2022

This timeout is scheduled here and here. In both cases, round is zero.

@fatcat22
Copy link
Contributor Author

This timeout is scheduled here and here. In both cases, round is zero.

You are right, sorry about my mistake. I was brosing the master branch at first, for after reading the development-procedure document, I supposed that master branch is the default dev branch. (Am I wrong anain, or the doc is out of date?)

Anyway, I still advise that using ti.Round but not 0, or adding assertion like if ti.Round != 0 panic(...). It up to you, if you think there's no need to do that, you can close this PR directly.

@cason
Copy link

cason commented Aug 17, 2022

No problems, and to nothing to be sorry about, you presented an evidence that this behavior is not clearly documented in the code.

@cason
Copy link

cason commented Aug 17, 2022

We migrated from master to main few weeks ago.

Copy link
Contributor

@williambanfield williambanfield left a comment

Choose a reason for hiding this comment

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

I still think we should make the change here, even if the it doesn't have an immediate effect. I wrote the code that used this method in master and assumed that it actually used the round number value. It introduced a bug just by using the code in the way one would reasonably assume it worked.

@cmwaters cmwaters merged commit c8302c5 into tendermint:main Aug 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

consensus: wrong round number when handling RoundStepNewRound timeout

5 participants