feat: migrate SpokePoolIndexer to new Indexer #64
Conversation
| this.insertWithFinalisationCheck( | ||
| entities.FilledV3Relay, | ||
| eventsChunk, | ||
| ["depositId", "originChainId"], |
There was a problem hiding this comment.
I think this could override invalid fills that are stored in the database, should we use another set of keys? Maybe the relayHash
| this.insertWithFinalisationCheck( | ||
| entities.RequestedSpeedUpV3Deposit, | ||
| eventsChunk, | ||
| ["depositId", "originChainId"], |
There was a problem hiding this comment.
Should we add updatedOutputAmount, updatedMessage and updatedRecipient? Taking into account there could be more than one speedUp event for a single deposit.
There was a problem hiding this comment.
I added the transaction hash as the 3rd component of the unique key 👍
| this.insertWithFinalisationCheck( | ||
| entities.TokensBridged, | ||
| eventsChunk, | ||
| ["chainId", "leafId", "l2TokenAddress", "transactionHash"], |
There was a problem hiding this comment.
If transactionHash changes due to the reorg, I'm thinking we might end having both the first event we saw and the finalised one in the database. But the delete unfinalised query should handle this case, right?
There was a problem hiding this comment.
But the delete unfinalised query should handle this case, right?
Good observation. and yes, the delete unfinalised query should handle it
| configStoreClient.eventSearchConfig.toBlock = blockRange.to; | ||
| hubPoolClient.eventSearchConfig.toBlock = blockRange.to; |
There was a problem hiding this comment.
this toBlock refers to the SpokePool's chain? Should we somehow translate that to mainnet block numbers?
There was a problem hiding this comment.
Ah, you're right. I removed the to blocks for the config client and hub client
No description provided.