docs: clarify multiple workers

Author: turadg

README.md

@@ -22,6 +22,13 @@ Sources of latency:
 - Processing time of blocks.
 - DB delay. OnFinality has some caching which batches DB operations.
 
+Mitigations:
+
+- Index with multiple workers.
+  - They allow up to five in **Change Compute Size**
+  - In a recent indexing, the rate went from 14 to 50 blocks/sec (from 1 to 5 workers)
+    - Diminishing returns are to be expected because the blocks are always processed in order, so workers are often waiting their turn.
+
 ## Developing
 
 This should be the same as the [Agoric SubQuery project](https://github.com/Agoric/agoric-subql). See [Developing](https://github.com/Agoric/agoric-subql/blob/main/README.md#developing) in its README.

src/mappings/events/fastUsdc.ts

@@ -21,10 +21,15 @@ export const transactionEventKit = (block: CosmosBlock, data: StreamCell, module
     const { height } = block.header;
     const time = block.header.time as Date;
 
-    // XXX this assumes that records will be processed in order,
-    // so multiple indexer workers is not supported.
     const t = await FastUsdcTransaction.get(id);
     if (!t) {
+      // NB: This really should not happen. The earlier entry in vstorage for any transaction
+      // is always an OBSERVED. I put this condition here because the indexer
+      // did fail at least once without it. I think it was when I started
+      // indexing with multiple workers and for that reason I thought the
+      // workers would proces blocks out of order. But the devs at OnFinality
+      // said: The workers allow fetching blocks out of order but they are still
+      // processed in order. (BLock 51 will always be processed after 50).
       if (payload.status !== FastUsdcTransactionStatus.OBSERVED) {
         console.error('new status ${payload.status} for ${id} without a previous OBSERVED');
         return [];