On secondaries, inserts/updates into config.image_collection happen inside the transactions that perform the data write. But deletes are replicated explicitly. Thus if a batch contains both a data write that wants to upsert an image_collection document as well as a delete of that document, they can be executed out of order by different threads.

This can manifest in two ways:

• If this is a new image_collection document, that document will be leaked on secondaries that do the writes out of order.
• If the this is an update to an existing image_collection document, an out of order write assertion will crash the process. No data is corrupted. Restarting the secondary will eventually succeed.

Also note that tripping this bug requires an unlikely ingredient. Logical sessions on primaries are reaped after a configured amount of inactivity (minutes). This bug requires either:

• A secondary applying a batch that spans an entire reaping window.
• A client that stops using a logical session for long enough to reap it. But then uses the LSID again right as its being reaped.