Avoid accidentally skipping blocks when switching to live sync #363
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Pull Request Overview
This PR addresses a potential issue of skipping blocks during the transition from historic to live sync by adjusting the block range for fetching logs.
- Introduces a variable (last_processed_block) to capture the last processed block.
- Updates the fetch_logs call to start fetching from last_processed_block + 1 instead of the relevant block number.
| @@ -661,7 +663,7 @@ impl SsvEventSyncer { | |||
|
|
|||
There was a problem hiding this comment.
Ensure that adding 1 to the last_processed_block correctly handles the intended block range without causing an off-by-one error. Consider adding a comment to clarify why the increment is necessary.
| // Fetch logs starting from the next block after the last processed block. | |
| // The increment (+1) ensures we do not reprocess the last processed block. |
Copilot uses AI. Check for mistakes.
| @@ -641,7 +641,9 @@ impl SsvEventSyncer { | |||
|
|
|||
| // If the relevant block was already processed, do not process it again. This can | |||
There was a problem hiding this comment.
Should this be updated? What does a relevant block mean?
There was a problem hiding this comment.
No, this comment still applies.
The relevant block is the newest block we want to get. It is 8 blocks before the head of the chain.
| @@ -661,7 +663,7 @@ impl SsvEventSyncer { | |||
|
|
|||
| let mut logs = self | |||
| .fetch_logs( | |||
| relevant_block, | |||
| last_processed_block + 1, | |||
There was a problem hiding this comment.
Was passing relevant_block twice a bug?
There was a problem hiding this comment.
Yes. Before, we were not guaranteed to fetch all logs. For example, when switching from historic to live sync, we may miss a block, and passing relevant_block twice returns only logs for that block. By requesting the range of blocks from the last processed block to the relevant block, we avoid this.
If a block happens just as we switch from historic to live sync, we may miss a block. This is highly unlikely, but possible.
This PR gets the logs from the block after the last processed block to the relevant block, instead of only the relevant block. In most cases, this should be equivalent, but it can't hurt to make sure.