Skip to content

Conversation

@0xNeshi
Copy link
Collaborator

@0xNeshi 0xNeshi commented Nov 17, 2025

Resolves #56
Resolves #76
Resolves #5
Resolves #155

@0xNeshi 0xNeshi self-assigned this Nov 17, 2025
use tracing::{debug, error, info, warn};

#[allow(clippy::too_many_arguments)]
pub(crate) async fn stream_live_blocks<N: Network>(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the amount of changes to the block_range_scanner.rs, it was becoming hard to understand the implication of those changes.

I figured it would be a good time to extract these common functions and to refactor handle_sync for two reasons:

  1. Easier to review - stream_live_blocks and stream_historical_blocks behave completely differently from before, and can be regarded as completely new functions. Moving them to common.rs makes the reviewer look at these functions for what they are - new functions.
  2. Show what the future BlockRangeScanner refactor could look like (see sync_handler.rs) - each mode would be its own "strategy" type.

@0xNeshi 0xNeshi marked this pull request as ready for review November 20, 2025 12:17
Comment on lines +381 to +388
let sync_handler = SyncHandler::new(
self.provider.clone(),
self.max_block_range,
start_id,
block_confirmations,
sender,
);
sync_handler.run().await
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a strategy-like pattern that we could use for mode handling. The logic is all contained within the strategy type.

@0xNeshi 0xNeshi marked this pull request as draft November 21, 2025 09:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: enhancement Improvement to existing functionality type: feature New functionality type: refactor Code improvement without changing functionality

Projects

None yet

2 participants