Reorg depth counter is incorrect

[philknows]

Describe the bug

Recent reorgs are not properly being shown in our metrics. @wemeetagain investigated why our metrics cannot properly show and calculate reorgs and their depths. Reorg depth is currently calculated as newHead.slot - commonAncestor.slot

Expected behavior

The reorg depth counter should be able to determine reorgs and at what depth. We need to tweak the calculation with something else. @wemeetagain suggests maybe Math.max(newHead.slot, oldHead.slot) - commonAncestor.slot

Open for discussion/solutions.

[maschad]

In the case of a reorg wouldn't the newHead.slot always be greater than the oldHead.slot ? I understand the reorg depth as the difference between the new chain and the old chain so therefore:

(newHead.slot - commonAncestor.slot) - (oldHead.slot - commonAncestor.slot)

[wemeetagain]

Not necessarily.

We had a recent case like so:

• block xxx01 is processed and becomes head
• block xxx03 thru xxx24 is processed and becomes head
• block xxx02 is processed and becomes head

In this case our reorg depth counter registered a reorg of depth 1, even though the reorg went from 24 back to 2

[wemeetagain]

Other strange case, in deep reorgs, the shufflings are different, and there can be multiple blocks at the same slot.

[maschad]

Using Prysm's calculation it seems like the find the max of the two differences between the new slot, the old slot and the common ancestor slot.

so essentially

Math.max((newHead.slot - commonAncestor.slot), (oldHead.slot - commonAncestor.slot))