Conversation
| this.indexMissingBlocksTask.name, | ||
| serialized | ||
| ); | ||
| } catch (error) { |
There was a problem hiding this comment.
Let's leave that to the queue implementation to handle errors that come from this. Generally, catching stuff early and not handling it (just emitting it is not handling it imo) lead to weird and non-recoverable behaviour.
Throwing stuff is okay, sometimes stuff just breaks down, but then the sequencer should crash and restart.
At least that's the ideal philosophy I try to approach these things nowadays. Idk I just thought I'd share this - here it's definitely not missing critical so it might be unwise to let the sequencer crash because of a peripherial system. Yeah idk let's talk about it more i guess
| const currentHeight = await this.blockRepository.getCurrentBlockHeight(); | ||
|
|
||
| if (incomingHeight > currentHeight) { | ||
| if (firstBlockHeight > currentHeight) { |
There was a problem hiding this comment.
Ideally, I'd like a few comments here on why this works (internal consistency given by the DB) bcs that fact is not immediately apparent
| input: IndexBlockTaskParameters[] | ||
| ): Promise<IndexBlockResult> { | ||
| const incomingHeight = Number(input.block.height.toBigInt()); | ||
| const firstBlockHeight = Number(input[0].block.height.toBigInt()); |
There was a problem hiding this comment.
Here - do we have the gurantee that those are in-order?
There was a problem hiding this comment.
We have two scenarios here:
- In normal indexing, we only receive a single block.
- If we receive multiple blocks, it means we’re indexing missing blocks that were generated using
Array.from()
… feat/indexer-recover-blocks
2 participants
closes #480