During the cloning phase of a migration, in addition to transferring CRUD ops, the donor shard transfers the oplog entries associated with new retryable writes to the recipient shard, so the writes can still be retried if the migration succeeds. This is done by adding the opTimes of retryable write oplog entries to the donor shard cloner's SessionCatalogMigrationSource in WriteUnitOfWork commit handlers registered in insert/update/delete op observers and returning the entries associated with those times when the recipient shard calls _getNextSessionMods on the donor.

When transactions are committed, a commit transaction op observer fires that runs the CRUD op observers for each write in the transaction. Currently these CRUD observers are run with the opTime of the commit oplog entry and will add this opTime to the migration cloner's SessionCatalogMigrationSource, if it exists, leading _getNextSessionMods to transfer the commit oplog entry to the recipient shard.

This can lead to migration failures when the recipient checks out the TransactionParticipant associated with the commit, because the migrating thread assumes the txnId is for a retryable write and will throw InvalidOptions if the recipient was involved in the transaction and its TransactionParticipant isn't in the expected state for a retryable write (i.e. kNone).

Only the oplog entries for retryable writes need to be transferred, so this can be fixed by never passing an opTime from a transaction statement to the SessionCatalogMigrationSource in MigrationChunkClonerSourceLegacy.