fix: added MAXIMUM_GOSSIP_CLOCK_DISPARITY into account to distinguish future slots #1316
Conversation
|
After various tests, I've spotted no more warnings related to blocks being received a couple of milliseconds before. while still seeing them in the main branch, specially at different times of the day. |
| @doc """ | ||
| Get the current chain slot based on the system time. | ||
|
|
||
| TODO: There are just 2 uses of this function outside this module: |
There was a problem hiding this comment.
If there's a TODO, please add an issue and refer to it inside the todo. If not, remove the TODO.
There was a problem hiding this comment.
The TODO was old, you are right, I didn't saw this comment immediately. Removing it in the other PR now that I need to merge main again!
Completely agree, now at least the 2 more used functions are in the same module but we still need to unify them, I'll add an issue! |
#1322 was created! |
Motivation
This PR fixes an issue where some blocks where ignored (6000656 started at 21.11.12 for us)
WARNING 21:11:11.831 [Gossip] Block ignored, reason: "Block is from the future: block.slot=6000656. Current slot: 6000655.".Description
In fact, the blocks where being received in time, just a couple of milliseconds before we made the transition, having into account
MAXIMUM_GOSSIP_CLOCK_DISPARITYin the calculation, allow us to process the block at the time.I also moved the current_slot function from
StoretoForkChoice, to have both depending on the same calculation. There is an outstanding function that previously used the oldClock.get_current_time/0that is using the system time since then, I added a comment where it is used for future reference, the function is:get_current_chain_slot/0.Resolves #1315