fix: handle a race condition between the signer and the /v2/pox endpoint #4738
Conversation
When the signer is processing a new burn block, it may hit the /v2/pox endpoint before it has been updated with the latest block. This change will check for this case and retry until it receives the expected cycle.
This handles the case where for the first block in a cycle (height % cycle_length == 0), it will report that it is in cycle N, but it will also report that it is in the prepare phase. This was resulting in refreshing the signer config too early. For example, with a cycle length of 20, at block 160, we would see a log: ``` Received a new burnchain block height (160) in the prepare phase of the next reward cycle (9). Checking for signer registration... ``` This is incorrect, because block 160 is not in the prepare phase for cycle 9.
|
I got a little excited and pushed too soon. Will fix and post here when it is ready for review. |
obycode
force-pushed
the
fix/signer-cycle-transition
branch
from
faae28d
to
40b1603
Compare
|
Ok, I think the last change is good. I am testing now locally. |
|
Something is not working still with this yet. The signers are never recognizing that they are registered. Investigating now. |
It's okay if it returns a higher cycle than expected.
|
Ok, ready for review again. 🙏 |
There was a problem hiding this comment.
LGTM -- can you create an issue for testing this scenario? I think that we want to make sure in a realistic testing environment that signers are able to sign new blocks during the 0th tenure of a reward cycle. If there's a race condition in the /v2/pox endpoint which prevents it from updating on time, its possible it could trigger "off by one" like behavior for the 0th tenure. I think this patch fixes that, but its something we want to be sure to confirm.
When the signer is processing a new burn block, it may hit the /v2/pox endpoint before it has been updated with the latest block. This change will check for this case and retry until it receives the expected cycle.
This also fixes a problem with refreshing the signer too early. It should only attempt to refresh the signer during the next prepare phase. This handles the case where for the first block in a cycle (height % cycle_length == 0), it will report that it is in cycle N, but it will also report that it is in the prepare phase. This was resulting in refreshing the signer config too early. For example, with a cycle length of 20, at block 160, we would see a log:
This is incorrect, because block 160 is not in the prepare phase for cycle 9.