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
The flexibility provided by `EventFilter` allows you to build sophisticated event monitoring systems that can track events at different granularities depending on your application's needs.
165
189
190
+
### Event Filter Batch Builders
191
+
166
192
Batch builder examples:
167
193
168
194
```rust
@@ -182,32 +208,40 @@ let multi_sigs = EventFilter::new()
182
208
]);
183
209
```
184
210
185
-
### Scanning Modes
211
+
### Message Types
186
212
187
-
-**Live** – `EventScanner::live()` creates a scanner that streams new blocks as they arrive. On detecting a reorg, the scanner emits `ScannerStatus::ReorgDetected` and recalculates the confirmed window, streaming logs from the corrected confirmed block range.
188
-
-**Historic** – `EventScanner::historic()` creates a scanner for streaming events from a past block range. Currently no reorg logic has been implemented (NOTE ⚠️: still WIP).
189
-
-**Latest Events** – `EventScanner::latest()` creates a scanner that streams the specified number of recently emitted events. On detecting a reorg, the scanner re-fetches all of the events in the specified block range (default: Earliest..=Latest).
190
-
-**Sync from Block** – `EventScanner::sync().from_block(start)` creates a scanner that streams events from a given start block, and then automatically transitions to live streaming. Reorgs are handled as per the particular mode phase the scanner is in (historic or live).
191
-
-**Sync from Latest** - `EventScanner::sync().from_latest(count)` creates a scanner that streams the most recent `count` events, then automatically transitions to live streaming. Reorgs are handled as per the particular mode phase the scanner is in (latest events or live).
213
+
The scanner delivers three types of messages through the event stream:
214
+
215
+
-**`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.
216
+
-**`Message::Status(ScannerStatus)`** – Status notifications from the scanner:
217
+
-**`Message::Error(ScannerError)`** – Error notifications if the scanner encounters issues (e.g., RPC failures, connection problems)
218
+
219
+
Always handle all message types in your stream processing loop to ensure robust error handling and proper reorg detection.
220
+
221
+
222
+
### Scanning Modes
192
223
193
-
#### Configuration Tips
224
+
-**Live** – scanner that streams new blocks as they arrive.
225
+
-**Historic** – scanner for streaming events from a past block range (default: genesis..=latest).
226
+
-**Latest Events** – scanner that collects up to `count` most recent events per listener. Final delivery is in chronological order (oldest to newest).
227
+
-**Sync from Block** – scanner that streams events from a given start block up to the current confirmed tip, then automatically transitions to live streaming.
228
+
-**Sync from Latest Events** - scanner that collects the most recent `count` events, then automatically transitions to live streaming.
194
229
195
-
- Set `block_read_limit` based on your RPC provider's limits (e.g., Alchemy, Infura may limit queries to 2000 blocks)
196
-
- For live mode, if the WebSocket subscription lags significantly (e.g., >2000 blocks), ranges are automatically capped to prevent RPC errors
197
-
- Each mode has its own appropriate configuration options for start block, end block, confirmations
198
-
- The modes come with sensible defaults; for example not specifying a start block for historic mode automatically sets the start block to the genesis block.
230
+
#### Important Notes
199
231
200
-
See the integration tests under `tests/` for concrete examples.
232
+
- 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.
233
+
- The modes come with sensible defaults; for example, not specifying a start block for historic mode automatically sets it to the genesis block.
234
+
- For live mode, if the WebSocket subscription lags significantly (e.g., >2000 blocks), ranges are automatically capped to prevent RPC errors.
201
235
202
236
---
203
237
204
238
## Examples
205
239
206
-
-`examples/live_scanning` – minimal live-mode scanner using `EventScanner::live()`
207
-
-`examples/historical_scanning` – demonstrates replaying historical data using `EventScanner::historic()`
208
-
-`examples/sync_from_block_scanning` – demonstrates replaying from genesis (block 0) before continuing to stream the latest blocks using `EventScanner::sync().from_block(block_tag_or_number)`
209
-
-`examples/latest_events_scanning` – demonstrates scanning the latest events using `EventScanner::latest()`
210
-
-`examples/sync_from_latest_scanning` – demonstrates scanning the latest events before switching to live mode using `EventScanner::sync().from_latest(count)`.
240
+
-`examples/live_scanning` – minimal live-mode scanner using `EventScannerBuilder::live()`
241
+
-`examples/historical_scanning` – demonstrates replaying historical data using `EventScannerBuilder::historic()`
242
+
-`examples/sync_from_block_scanning` – demonstrates replaying from genesis (block 0) before continuing to stream the latest blocks using `EventScannerBuilder::sync().from_block(block_tag_or_number)`
243
+
-`examples/latest_events_scanning` – demonstrates scanning the latest events using `EventScannerBuilder::latest()`
244
+
-`examples/sync_from_latest_scanning` – demonstrates scanning the latest events before switching to live mode using `EventScannerBuilder::sync().from_latest(count)`.
0 commit comments