tron: add hot blocks support #345
Conversation
| } | ||
|
|
||
| async getFinalizedHeight(): Promise<number> { | ||
| let height = await this.getHeight() | ||
| return height - this.finalityConfirmation |
There was a problem hiding this comment.
Should never be negative.
|
|
||
| let self = this | ||
|
|
||
| let from = requests[0].range.from - 1 |
There was a problem hiding this comment.
What if we start from zero?
| top: [], | ||
| }, | ||
| { | ||
| process: async (update) => { queue.push(update) }, |
There was a problem hiding this comment.
Just realised, that src.getBlockStream() interface for hot blocks requires handling data consistency errors on a processor side as well.
For example, consider the case, when storage request was made to a block that is already gone.
Currently we don't handle this in the SDK, but prev callback based interface for hot blocks had ability to do that.
| @@ -79,6 +79,10 @@ export class TronGateway { | |||
| })) { | |||
| let req = getRequestAt(requests, batch.blocks[0].header.number) | |||
|
|
|||
| // FIXME: needs to be done during batch ingestion | |||
| let finalizedHeight = await this.getFinalizedHeight() | |||
There was a problem hiding this comment.
There is no need for this. Simply take the last block in the batch as finalized.
There was a problem hiding this comment.
Ah, now I understand what you mean in this comment, but this is some odd behavior. Finalized head should never decrease
If you write stream data directly to a message queue, you won't expect a such trap
| !!opts.supportHotBlocks || opts.stopOnHead | ||
| )) { | ||
| // FIXME: needs to be done during batch ingestion | ||
| let finalizedHeight = await this.getFinalizedHeight() |
There was a problem hiding this comment.
There is no need for this. Simply take the last block in the batch.
No description provided.