Historic Mode Reorg Handling

[0xNeshi]

[0xNeshi]

Sync Mode: Live Phase Shouldn't Emit ReorgDetected for Reorgs Related to Historical Phase

Because historic and live streams run in parallel (with the former being streamed first, then the latter, to maintain ordering), when a reorg happens during historic phase that affects blocks in the historic block range, the live stream will detect the same reorg, eventually emitting a duplicate ReorgDetected notification when its phase begins and streaming duplicate logs (already streamed in historic phase). This would cause duplicate log processing, potentially breaking app flows and state managements in particular use cases.

To propose a solution through an example, let's say the current block number is 100 when sync mode function is called. Ideally, if any reorg happened during historic phase, the historic phase should handle it, but the live stream should be aborted and discarded, and instead the sync mode should be "reset" with start_height = 101. If a new reorg happens during the historic phase of this restarted sync mode call, the same algorithm is applied as before, and this is repeated until no reorgs are detected in the historic phase of the currently running sync mode.
That way, no blocks are ever missed, and the "live phase", which is now recreated sync mode, always streams up-to-date, post-reorg blocks with no duplicate reorg handling.