Predicting the expected next proposer stopped working after upgrading from v0.34 to v0.37

[outofforest]

We developed a metric allowing us to monitor validators who don't propose a block. To do that we compare expected proposer with the real one. Finding the real one is easy - it is the ProposerAddress field in the block.

Finding the expected one is tricky. I did that by looking at ProposerPriority field of each validator stored in the previous block, according to the procedure described at https://docs.cometbft.com/v0.37/spec/consensus/proposer-selection.

I'm assuming that the next validator is the one with the highest ProposerPriority. Here is the code:

	expectedNextProposer := vals.Validators[0]
	if len(vals.Validators) > 1 {
		for _, v := range vals.Validators[1:] {
			if v.ProposerPriority > expectedNextProposer.ProposerPriority {
				expectedNextProposer = v
			}
		}
	}

This logic served well, until we upgraded to v0.37. After that, our metric started reporting crazy data.
Has anything related to this algorithm changed in the past releases?

[lasarojc]

Hi @outofforest
There has been no change in the algorithm. I am no specialist in the algorithm, but AFAICT, your metric is missing a step. If priorities are equal, the node with higher address, compared lexicographically, will be the proposer. See CompareProposerPriority in the validator.go file.

Converting this into a discussion. We can convert back to issue later, if needed.