During the first drain phase of hybrid index builds, operations are applied in batches from the side table record store into the index. At the end of each batch (1000 operations by default), the side table cursor is saved and restored. This restore may reposition on new records, but not necessarily the newest records. This can cause batch applications after yield to apply causal operations out of order.

For example, imagine two writer threads, A and B, writing into the side table and an index build thread. In this example, thread A inserts then deletes the key {a: 1}. Thread B inserts an unrelated key.

In this scenario, it is possible to insert the key {a: 1} into the index even after it has been deleted.

The fix for this bug should be to reposition cursors at the beginning of the record store after every yield to guarantee all causally related records are applied in order.