Copy from: streamingfast/merger#31
In the case where a one-block arrives late (late defined as after merger has already created a merged-block), the merger should evaluate the one-block as to if the one-block is already included in the merged-blocks or if it is a "forked block" and should be written to forked blocks.
When this happens: readers might be sending blocks to live firehose users but those blocks are delayed being send to the merger due to network issues. When you run different firehose components in different parts of the planet, weird things can happen.
If the one-block file is older than the "retain forked blocks" time period, then the one-block should simply be discarded (as today).
If not, read the one-block, read the merged-block, then take the decision on what to do (throw away or write to forked blocks)
Copy from: streamingfast/merger#31
In the case where a one-block arrives late (late defined as after merger has already created a merged-block), the merger should evaluate the one-block as to if the one-block is already included in the merged-blocks or if it is a "forked block" and should be written to forked blocks.
When this happens: readers might be sending blocks to live firehose users but those blocks are delayed being send to the merger due to network issues. When you run different firehose components in different parts of the planet, weird things can happen.
If the one-block file is older than the "retain forked blocks" time period, then the one-block should simply be discarded (as today).
If not, read the one-block, read the merged-block, then take the decision on what to do (throw away or write to forked blocks)