wormhole-foundation / wormhole-explorer

We could have named this super-parakeet. Tweet tweet.
Other
30 stars 28 forks source link

[BUG] Case with inconsistency between vaa and txHash #1283

Open walker-16 opened 5 months ago

walker-16 commented 5 months ago
### Tasks
- [ ] https://github.com/wormhole-foundation/wormhole-explorer/issues/1300
- [ ] https://github.com/wormhole-foundation/wormhole-explorer/issues/1301
- [ ] https://github.com/wormhole-foundation/wormhole-explorer/issues/1303
walker-16 commented 5 months ago

case with error: https://wormholescan.io/#/tx/0x082ae626bcad413d3ea027736737892e6782ffaf64fd98d09b73a64eadfd81ed https://wormholescan.io/#/tx/0x3ba97bd2e8193eea321c6e21ec4146e458d20f2b8ccb1cbd3212f84cd112dcda

M-Picco commented 5 months ago

The explorer backend was initially designed under the assumption that the vaa id (chain id/emitter/sequence) would be unique; however, it turns out that it might be the case for multiple VAAs with instant finality to be emitted under the same sequence on transactions that can later get dropped or reordered upon chain reorgs.

After discussing the different approaches to deal with this situation, we decided that the best for now would be to adapt the backend to store this "duplicated" vaas on a secondary collection which could be queried and mark those vaas on the main collection as "dirty" to point out potential duplicates for the same id. A worker process would later analyze the duplicates on the secondary collection to detect those which were emitted on transactions that reached finality.

I'll edit the description with two tasks: one for the fly modifications and another for the background process. Further down the line we'll probably add an additional task to reprocess those vaas that were stored on the duplicates collection but actually made it to finality, thus attempting to make the main vaas collection as closest as the blockchain as possible.

Related documents: original issue analysis; discussion meeting notes