Open shinyfoil opened 2 years ago
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:
Problem:
Block
43271612
has four confirmed TX in block definition, however only two (0x4510e90baf2a6c1603e55e8c9b7ee53a1f1d5d23af3dcd2fca4ed6e613bcc7f3
and0x6ff3f26018429baa67a709c41847b601cd7b2e663973aa5e0eaf3cc653df0523
) were actually confirmed in this block. TX's0x7563789c2faf867ca69328de1f14d19ccf0601792b0171dac645651d1ee84837
and0xf8d6ed3c768ac7c7d7603cd3b288e09a8d6546634a51f48187c41a502413f006
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: