Found via code inspection in a CR.

performInserts takes as input a write_ops::Insert (a vector of documents) and returns a result that contains a vector of errors (results*). It's possible for some earlier writes to contain errors while later ones succeed. However, consider the example where an input batch contains 2 writes: {not yet executed insert, already executed insert}. The output results will be for {already executed insert, not yet executed insert}.

This comment demonstrates a scenario where I believe the bug in performInserts can manifest as a wrong response to a user.

My understanding is that today we have no bug. In all cases when the function is called, retryable writes are always at the beginning of the batch (I haven't verified this). But we are adding new code that uses this method and in ways where the writes may be relatively opaque (sourced by the oplog).

I think adding an invariant to formalize the contract or being more careful about batching are both acceptable outcomes.

Assigned to sharding for a first look as this seems specific to retryable writes.