You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+7-3Lines changed: 7 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -230,11 +230,15 @@ let multi_sigs = EventFilter::new()
230
230
The scanner delivers three types of messages through the event stream:
231
231
232
232
-**`Message::Data(Vec<Log>)`** – Contains a batch of matching event logs. Each log includes the raw event data, transaction hash, block number, and other metadata.
233
-
-**`Message::Notification(Notification)`** – Notifications from the scanner:
234
-
-**`ScannerError`** – Errors indicating that the scanner has encountered issues (e.g., RPC failures, connection problems)
233
+
-**`Message::Notification(Notification)`** – Notifications from the scanner.
234
+
-**`ScannerError`** – Errors indicating that the scanner has encountered issues (e.g., RPC failures, connection problems, or a lagging consumer).
235
235
236
236
Always handle all message types in your stream processing loop to ensure robust error handling and proper reorg detection.
237
237
238
+
Notes:
239
+
240
+
- Ordering is guaranteed only within a single subscription stream. There is no global ordering guarantee across multiple subscriptions.
241
+
- When the scanner detects a reorg, it emits `Notification::ReorgDetected`. Consumers should assume the same events might be delivered more than once around reorgs (i.e. benign duplicates are possible). Depending on the application's needs, this could be handled via idempotency/deduplication or by rolling back application state on reorg notifications.
238
242
239
243
### Scanning Modes
240
244
@@ -248,7 +252,7 @@ Always handle all message types in your stream processing loop to ensure robust
248
252
249
253
- Set `max_block_range` based on your RPC provider's limits (e.g., Alchemy, Infura may limit queries to 2000 blocks). Default is 1000 blocks.
250
254
- The modes come with sensible defaults; for example, not specifying a start block for historic mode automatically sets it to the genesis block.
251
-
-For live mode, if the WebSocket subscription lags significantly (e.g., >2000 blocks), ranges are automatically capped to prevent RPC errors.
255
+
-In live mode, if the block subscription lags and the scanner needs to catch up by querying past blocks, catch-up queries are performed in ranges bounded by `max_block_range`to respect provider limits.
0 commit comments