fix(coprocesor): listener, typos

Author: rudy-6-4

listener/crates/listener_core/src/blockchain/evm/sem_evm_rpc_provider.rs

@@ -92,7 +92,7 @@ impl SemEvmRpcProvider {
         // Network policy blackholes (TCP keepalive detects silent drops)
         // Load balancer idle timeout alignment (10 s < any cloud LB timeout)
         let http_client = alloy::transports::http::Client::builder()
-            .timeout(Duration::from_secs(25)) // Must accomodate slow providers with high response time
+            .timeout(Duration::from_secs(25)) // Must accommodate slow providers with high response time
             .connect_timeout(Duration::from_secs(3)) // fast failure if the host is unreachable
             .pool_idle_timeout(Duration::from_secs(10)) // aggressive eviction of unused request.
             .pool_max_idle_per_host(max_concurrent_requests) // Match the semaphore size setting

listener/crates/listener_core/src/core/evm_listener.rs

@@ -733,7 +733,7 @@ impl EvmListener {
             &self.repositories,
             &block_n,
             chain_id_u64,
-            // This block is comming from the live flow, and detect the reorg processing, but was issued from the live flow.
+            // This block is coming from the live flow, and detect the reorg processing, but was issued from the live flow.
             BlockFlow::Live,
             &self.broker,
             &self.event_publisher,

listener/crates/listener_core/src/core/evm_listener.rs.orig

@@ -439,10 +439,10 @@ impl EvmListener {
     /// to `EvmListenerError::InvariantViolation`.
     pub async fn fetch_blocks_and_run_cursor(&self) -> Result<CursorResult, EvmListenerError> {
         // Pre verification:
-        // The prefetch count setted up to 1 allows us to simply verify emptiness of the queue/stream, to ensure there is no possibility of overlaping
+        // The prefetch count set up to 1 allows us to simply verify emptiness of the queue/stream, to ensure there is no possibility of overlapping
         // messages.
-        // If there is another message sitting in the queue, we can basically skip the message and avoid consuming it, by directly acknoledging.
-        // TODO: This is a first security, but not complient with horizontal scaling and needs to be locked.
+        // If there is another message sitting in the queue, we can basically skip the message and avoid consuming it, by directly acknowledging.
+        // TODO: This is a first security, but not compliant with horizontal scaling and needs to be locked.
         let fetch_topic = Topic::new(routing::FETCH_NEW_BLOCKS)
             .with_namespace(chain_id_to_namespace(self.chain_id));
         let task_lock = self
@@ -744,7 +744,7 @@ impl EvmListener {
         let chain_id_u64 = self.repositories.chain_id() as u64;
 
         // pre-check: Skipping duplicate messages.
-        // TODO: This is a first security, but not complient with horizontal scaling and needs to be locked.
+        // TODO: This is a first security, but not compliant with horizontal scaling and needs to be locked.
         let reorg_topic = Topic::new(routing::BACKTRACK_REORG)
             .with_namespace(chain_id_to_namespace(self.chain_id));
         let task_lock = self
@@ -786,7 +786,7 @@ impl EvmListener {
             &self.repositories,
             &block_n,
             chain_id_u64,
-            // This block is comming from the live flow, and detect the reorg processing, but was issued from the live flow.
+            // This block is coming from the live flow, and detect the reorg processing, but was issued from the live flow.
             BlockFlow::Live,
             &self.broker,
             &self.event_publisher,

listener/crates/listener_core/src/main.rs

@@ -140,7 +140,7 @@ async fn main() {
     ) {
         Ok(provider) => provider,
         Err(e) => {
-            error!("Could not instanciate the semaphore provider: {}", e);
+            error!("Could not instantiate the semaphore provider: {}", e);
             process::exit(1);
         }
     };
@@ -475,7 +475,7 @@ async fn main() {
 
     // let consumer_lib_handler_test =
     //     AsyncHandlerPayloadOnly::new(move |event: BlockPayload| async move {
-    //         // println!("Consumer recieved event: {}", event);
+    //         // println!("Consumer received event: {}", event);
     //         info!("GETTING EVENT FROM BLOCK: {}", event.block_number);
     //         Ok::<(), EvmListenerError>(())
     //     });

listener/crates/listener_core/src/main.rs.orig

@@ -114,7 +114,7 @@ async fn main() {
     ) {
         Ok(provider) => provider,
         Err(e) => {
-            error!("Could not instanciate the semaphore provider: {}", e);
+            error!("Could not instantiate the semaphore provider: {}", e);
             process::exit(1);
         }
     };
@@ -446,7 +446,7 @@ async fn main() {
 
     // let consumer_lib_handler_test =
     //     AsyncHandlerPayloadOnly::new(move |event: BlockPayload| async move {
-    //         println!("Consumer recieved event: {}", event);
+    //         println!("Consumer received event: {}", event);
     //         Ok::<(), EvmListenerError>(())
     //     });
 

listener/crates/shared/broker/src/amqp/consumer.rs

@@ -290,7 +290,7 @@ impl RmqConsumer {
                         }
                         HandlerOutcome::Nack => {
                             if let Some(b) = cb { b.record_success(); }
-                            debug!("Handler voluntarily yielded, requeueing at tail of main queue");
+                            debug!("Handler voluntarily yielded, requeuing at tail of main queue");
                             result.delivery
                                 .nack(BasicNackOptions { requeue: true, ..Default::default() })
                                 .await

listener/crates/shared/broker/src/redis/consumer.rs

@@ -1101,7 +1101,7 @@ impl RedisConsumer {
     ///
     /// Non-blocking: does NOT use Redis BLOCK argument. BLOCK commands on
     /// `ConnectionManager` (which wraps `MultiplexedConnection`) are
-    /// architecturally broken — a blocking call monopolises the shared TCP
+    /// architecturally broken — a blocking call monopolizes the shared TCP
     /// connection and hangs indefinitely on dead sockets (redis-rs #1236).
     ///
     /// Callers use client-side `sleep()` as the polling interval instead.

listener/crates/shared/broker/tests/redis_e2e.rs

@@ -684,7 +684,7 @@ async fn test_circuit_breaker_halts_consumption() {
 // Without a circuit breaker, the message remains in retry circulation.
 //
 // With CB (threshold=2, cooldown=5 s) the consumer pauses after 2 failures,
-// preventing any further XREADGROUP reads. The ClaimSweeper is neutralised by a
+// preventing any further XREADGROUP reads. The ClaimSweeper is neutralized by a
 // very long claim_min_idle (60 s) so it cannot accumulate delivery counts within
 // the 3 s observation window — keeping the dead stream empty.
 #[tokio::test]

listener/docs/library_notifier.md

@@ -6,7 +6,7 @@ Integrate event consuming for specific logs and filters for zama components, and
 
 ## Logic:
 
-This component consume blocks, transasctions, receipts from the different queues declared on rabbitmq, checks into its table to see if there is relevent filters or abi to watch, or even "from" or "to" sources if we need to watch for some transactions, register logs in a table, and forward to the internal logic of the components that need logs.
+This component consume blocks, transasctions, receipts from the different queues declared on rabbitmq, checks into its table to see if there is relevant filters or abi to watch, or even "from" or "to" sources if we need to watch for some transactions, register logs in a table, and forward to the internal logic of the components that need logs.
 
 Basically, the library is receipt parser.
 You refer a watcher, and match the current watcher from the receipt if we need to get process an event.
@@ -37,7 +37,7 @@ For inspiration regarding this library, There is an existing implementation for
 #### Minimal features:
 
 - Persist block height and resilient to failure mode.
-- Multichain by design (consuming multuple queues (blocks, transactions with receipts -> e.g logs) for each networks).
+- Multichain by design (consuming multiple queues (blocks, transactions with receipts -> e.g logs) for each networks).
 - Should consume all events even if they are not used (or rmq memory will grow).
 - Declare notifiers for dynamical events ABI
   - Store log watchers types into a postgres.
@@ -49,8 +49,8 @@ For inspiration regarding this library, There is an existing implementation for
 - Declare multiple watcher with a number of block confirmations if a block confirmation number is required (RPC url could be required for this). (e.g finality, safe or n confirmations blocks) based on events.
 - Ability to be aware of new available chain from rabbitmq.
 - different types of watchers (logs, tx)
-- OPTIONNAL: Cancel reorged events.
-- OPTIONNAL: Replay past blocks (should not need this with rmq, since its queueing messages).
+- OPTIONAL: Cancel reorged events.
+- OPTIONAL: Replay past blocks (should not need this with rmq, since its queuing messages).
 - Check altogether if problems with duplicate logs, and how to manage them in the zama internals (could be handled optionally) To get a unicity regarding logs and handle deduplication, we can if needed apply a semantic hash regarding log.
 - Metrics
 - Alerting.
@@ -64,7 +64,7 @@ For inspiration regarding this library, There is an existing implementation for
 - table 1: watcher
   - uuid, chainId, number of conf block ?, ABI, watcher type (tx, contract)
 - table 2: logs
-  - uuid, watcher_uuid, block_number, released (TRUE, FALSE), log (deserialised or not), UNCLE? (Not mendatory if leverage on block confirmations)
+  - uuid, watcher_uuid, block_number, released (TRUE, FALSE), log (deserialised or not), UNCLE? (Not mandatory if leverage on block confirmations)
 
 ## Schemes:
 

listener/docs/listener_core.md

@@ -14,18 +14,18 @@
 - Counter-intuitively, it is always the fresher information that will bring us the truth, especially regarding the past.
 - Transaction receipts contains all the logs
 - ReceiptRoot calculation, and block hash calculation ensure there is no missing logs for a given block.
-- Zero websocket, not resilent.
+- Zero websocket, not resilient.
 
 ## Goal
 
-The goal of this core algorithm is to fetch (http polling), blocks, transactions, receipt, by polling, handle reorogs properly by checking hash and parent hash, fetch new informations if needed to be consistent and aware of canonical chain and broadcast blocks, and transaction to the message broker for the library to be aware of new events.
+The goal of this core algorithm is to fetch (http polling), blocks, transactions, receipt, by polling, handle reorogs properly by checking hash and parent hash, fetch new information if needed to be consistent and aware of canonical chain and broadcast blocks, and transaction to the message broker for the library to be aware of new events.
 
 ## Logic / Algorithms
 
 ### Algorithm v1: Sequential poller and reorg checker
 
 This is a descriptive of a basic algorithm, which could be sufficient with chains that produces blocks in more time than an http call duration.
-This algorithm is sequential, and is just refered here for knowledge.
+This algorithm is sequential, and is just referred here for knowledge.
 
 If you need access to an existing implementation of this algorithm, ask and I will share you the implementation.
 
@@ -35,8 +35,8 @@ This algorithm leverages mostly on database, to perform checks, states updates,
 2. we register block, transactions of this block, and associated receipt.
    1. The receipt contains all the logs.
    2. We broadcast the block, and the transactions with receipts to given queues with chainId, to get almost real time performance, for being consumed and filtered by the library notifier over abi filter and contract address
-3. we compare current block parent hash, and previous block parent hash to detect if a reorg occured.
-   1. if it matches, we go back to the begining of the algorithm.
+3. we compare current block parent hash, and previous block parent hash to detect if a reorg occurred.
+   1. if it matches, we go back to the beginning of the algorithm.
    2. if it didn't match: Reorg is detected.
       1. we fetch one by one all the previous blocks by hash, we broadcast events in the same fashion we did previously. (BACKTRACKING)
       2. pass the other ones to UNCLES status.
@@ -45,7 +45,7 @@ This algorithm leverages mostly on database, to perform checks, states updates,
 
 ### Algorithm v2: Cursor Algorithm
 
-The major flaw with the v1 iterative poller algorithm, is the block production time for faster chains, such as Arbitrum, Monad, or even Solana later could be fater than a single http response call, database operations, and network time calls if levraging on rabbitmq to trigger block fetch and polling operations, cumulated operations could be more than 100/200ms only in average time. It does not keep up with chain with a smaller block time duration.
+The major flaw with the v1 iterative poller algorithm, is the block production time for faster chains, such as Arbitrum, Monad, or even Solana later could be faster than a single http response call, database operations, and network time calls if levraging on rabbitmq to trigger block fetch and polling operations, cumulated operations could be more than 100/200ms only in average time. It does not keep up with chain with a smaller block time duration.
 Also, if later a full chain indexer is needed, this is impossible to leverage on the first algorithm.
 
 Here is the proposed algorithm to address this flaw.
@@ -55,10 +55,10 @@ Here is the proposed algorithm to address this flaw.
 Resolving the http latency, and ensure no event is missed.
 
 1. We calculate a block range:
-   1. `min(blockHeight - currentRegisterdBlock, maxParallelBlockFetch + currentRegisterdBlock)`
+   1. `min(blockHeight - currentRegisteredBlock, maxParallelBlockFetch + currentRegisteredBlock)`
    2. or range given from an order to fetch the next block.
-2. We spawn parallel task to fetch blocks (http polling), and register them in an in memory datastructure (slots for new blocks). And we fetch receipt for thoses blocks (strategy pattern could be required for diffrernt chains implems (`eth_getBlockReceipts` or `eth_getTransactionReceipt`for each trasnaction))
-3. Optionnal: we recompute block hash: The rationale behind this, calculate receiptRoot and then block hash from receipt root and all other headers: this ensure that there is no inconsistency in receipts, hence logs contained in the receipts.
+2. We spawn parallel task to fetch blocks (http polling), and register them in an in memory datastructure (slots for new blocks). And we fetch receipt for those blocks (strategy pattern could be required for diffrernt chains implems (`eth_getBlockReceipts` or `eth_getTransactionReceipt`for each transaction))
+3. Optional: we recompute block hash: The rationale behind this, calculate receiptRoot and then block hash from receipt root and all other headers: this ensure that there is no inconsistency in receipts, hence logs contained in the receipts.
 
 #### task two: cursor, reorg check and event broadcaster
 
@@ -78,14 +78,14 @@ Resolving the http latency, and ensure no event is missed.
 - Event driven system to react to multiple events for the algorithm described above.
 - strategy pattern (handling chains that doesn't support `eth_getBlockReceipts` method, and solana later)
 - algorithm v2 implementation with eth_getBlockReceipt first.
-- tables to store minimal metadata (blocks, transactions and receipts) with status (CANNONICAL, UNCLE).
+- tables to store minimal metadata (blocks, transactions and receipts) with status (CANONICAL, UNCLE).
 - Sql cleaner feature.
-- OPTIONNAL: Finalized status.
+- OPTIONAL: Finalized status.
 - Block computer.
-- OPTIONNAL: data storage layer no-sql or S3.
+- OPTIONAL: data storage layer no-sql or S3.
 - push rabbitmq messages.
 
-## Additionnal: 
+## Additional: