Fix validation queue race condition in block approval vs validaiton submission #5497
Conversation
…ew hasn't updated between validation sumbission and approval Signed-off-by: Jacinta Ferrant <[email protected]>
… into bug/validation-queue-race-condition
… and add test Signed-off-by: Jacinta Ferrant <[email protected]>
I decided to do a different approach. So unfortunately we expect signers to sign block proposals as valid that arrive BEFORE the new burn block as valid even if the new sortition view would make them invalid....would get rejected as we would have a new sortition view. I changed it to use a much more simplified height check that is very rudimentary. It should NOT ever be used to replace check_proposal or the validation endpoint but combined wiht the ValidateOk, I think is sufficient... |
… into bug/validation-queue-race-condition
Signed-off-by: Jacinta Ferrant <[email protected]>
… into bug/validation-queue-race-condition
I broke bitcoind_forking_test and I think partial_tenure_forking. I am actually wondering if this change has uncovered more easily the race condition from the node and the signer about approving blocks that should not be approved. The miner is consistently pushing blocks to me that are not the expected length. I might wait for the hotfix to go through before I try resolving these CI issues. |
… into bug/validation-queue-race-condition
… into bug/validation-queue-race-condition
Signed-off-by: Jacinta Ferrant <[email protected]>
Signed-off-by: Jacinta Ferrant <[email protected]>
… into bug/validation-queue-race-condition
… into bug/validation-queue-race-condition
Closes #5496