Is a reorganization bug?

Bugs
1

I receive an event log from block 0x78fc6d4709ff7a2aa96642de99f0a49af000264e4f6be63454bdc3b42701b3ad (block number = 10517964) with the removed flag set to 1.
So, I remove all related changes in my database from this event.

However, I check this block in etherscan, this block is not reorganization.
Is this a bug in Infura?

2

Hi @hello, sometimes blocks can be re-orged out and then back in when two chains are competing for miners. Did you also get an event re-adding the block?

3

Hi @Leiya_Kenney, do you means following scenario is possible?

  1. 10517964 (block hash = 0x78fc6d47, removed=0)
  2. 10517964 (block hash = 0x78fc6d47, removed=1)
  3. 10517964 (block hash = 0x78fc6d47, removed=0)
4

That’s exactly it! This will happen if there are two different chains that are building off a different base. This usually settles down in a block or two, but sometimes you’ll see it switch in and out a couple/few times.

5

Thanks for your confirmation. I hadn’t consider that situation. :crazy_face:

6

@Leiya_Kenney Can I distinguish 1 and 3 ?

  1. 10517964 (block hash = 0x78fc6d47 , removed=0)
  2. 10517964 (block hash = 0x78fc6d47 , removed=1)
  3. 10517964 (block hash = 0x78fc6d47 , removed=0)

Is there something different between 1 and 3? For high reliability, we deploy multiple application instances subscribe same event log. We use db unique index (block_hash, removed, log_index) to remove dup event log from multiple subscriber. So, I need to distinguish 1 and 3.

7

Those are the same block, but there was another block that we don’t know the hash of that was initially competing for that same number with the miners.