Jun 23, 2026

Think of it this way... there is a continuous flow of values into a table, and into a vector. The table writes are concurrent by block and at the granularity of tx outputs. The vector writes are sequential (stranded) by block (input would be way too much to message-buffer, blocks is easy/slow). The vector is only submitted to the message pump after the table writes for that block are committed. The critical section only makes write and verify/purge mutually-exclusive (and since verify is extremely rare, there is no meaningful contention). The strand will deliver batched messages to the vector at any time, but cannot do so during verify, because both are on the same strand. So batched cannot be increased during verify, and is purged at the end of verify. So a latent block id making its way through the message pump may land on batched after the table(s) that contained the records for that same block are purged. This doesn't matter. The tables only carry verification failure, so if the block failed, it's a reset. This latent block id will land once verification completes and has purged both the tables and the batched_ vector. This is fine. The block will get marked as valid on the next verification. The final (residual) batches ensure that both the tables and the batched_ vector are processed in full before batching gives way to non-batching.