Do not process block validation responses for the wrong reward cycle #5612
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@obycode discovered that the recent stall was due to the WRONG signer (one from prior reward cycle) processing a block validation response and attempting to broadcast when it thought it had enough signatures. The block proposal itself was already reward cycle gated but not the block validationr esponse. This caused some inifite looping in a signer that tried to broadcast a signed block that met its own reward cycle threshold but not the actual reward cycle threshold of the current reward cycle.
This should be fixed in the event parity check but that would require changes to the node. This is just a hotfix for the signers only.
This only became an issue now because of a change I made to the signer db: we no longer query the db based on reward_cycle (this never was a problem before because when we would go to query for a block using its signer signature hash, we would also pass in our own reward cycle. This would then never return a matching block info and then the block validation request would not apply)