Description

TL;DR: This is actually an existing race condition and can be triggered today. This can happen when blobs arrived from RPC and gossip around the same time and both triggering a block import. There's no impact other than extra work performed: in the 2nd import, the state cache is expected to miss, as the previous import pop'd the state, so this will result in state reconstruction, which takes ~80ms.

PeerDAS occurence

On peer-das-devnet-2, I'm seeing the same block getting written to the database multiple times (4 times within 2 ms!). This occurred on a supernode.

I think this is because we keep the PendingComponents in the cache until we complete block import, so for each gossip component that made it through to the DA checker after the block is available, it would trigger another import:

With PeerDAS supernodes, once we receive 64 columns, the remaining columns can come from reconstruction and block can be made available after this. However, we can still get columns from gossip (as they haven't been seen via gossip), and each of these gossip columns could trigger a block import, as the PendingComponent in the cache is "complete".

The change to keep PendingComponent in the DA cache was intentional and was made in the following PR to address an issue with sync lookup:
#5845

I'm not sure if there's a better way, but if we do need to keep the block in the DA Checker during import, perhaps we can do a check before trying to process a gossip block/blob/data_column - if block has already been made available, just return instead of processing and re-importing.