Handle duplicate transactions in block 43271612/43271618

[shinyfoil]

Problem:

Block 43271612 has four confirmed TX in block definition, however only two (0x4510e90baf2a6c1603e55e8c9b7ee53a1f1d5d23af3dcd2fca4ed6e613bcc7f3 and 0x6ff3f26018429baa67a709c41847b601cd7b2e663973aa5e0eaf3cc653df0523) were actually confirmed in this block. TX's 0x7563789c2faf867ca69328de1f14d19ccf0601792b0171dac645651d1ee84837 and 0xf8d6ed3c768ac7c7d7603cd3b288e09a8d6546634a51f48187c41a502413f006 were confirmed in the later block (per their tx result query) and in the confirmed list from the block.

This issue was confirmed by Hong from the Foundation, and shouldn't recur in the future, so putting in a special handling case is probably going to be the safest way to do it while also being explicit about the output we're expecting.

Proposed fix:

In block mapper, we can put in a special conditional to remove the two transactions from block 43271612's confirmed transaction list.

Justification:

The two transactions that were doubly "confirmed" only have logs in the later block, so removing them from the earlier block's list shouldn't result in duplicated data and should keep the rest of the values consistent. While this doesn't necessarily reflect the actual data stored in the chain, there aren't many other good alternatives.

Less good alternatives:

• Keep transactions in both confirmed lists
  • This would require overriding the way enrichment works (not using block number as the joining field) which would prevent us from finding any future recurrences of this issue
• Modify transaction hash (similar to what Foundation tracker is doing)
  • Foundation tracker has changed the hash of the earlier transactions, but this effectively breaks their tracker

[shinyfoil]

Slight wrinkle in this. Hong from the Foundation says that the two sets of transactions did actually get executed, but only the last result was retained. If it is the case that the state of the chain was changed by the two sets of transactions, we're going to have to figure out a way of correctly representing this.

Some ideas:

• append some sort of numeric indicator after the transaction hash to create unique transactions
  • requires some customization to modify the transaction hash. would require that the transactions be identical in all aspects (other than the block proposer?)
• leave the references to the transactions in the first block pointing to the result of the second
  • same issues as earlier w.r.t. identical transactions
• something else? we're talking with Foundation about how to proceed and if there's another option