Currently, there is no need to transfer transaction related state from one shard to another because it is not possible for transactions to run across migration boundaries. In most cases, this is already true because of the fact that:

1. Transaction related oplog entries have non-sensical ns field, like admin.$cmd for prepare entries, so they get naturally filtered out.
2. Transaction related ops don't have opTime assigned to them during the opObserver onInsert/Update/Delete, so they don't get transferred during session xferMod phase.

However, in the case when the transaction commits but the oplog entry it points to gets truncated (because oplog rolled over), the session migrate will generate a sentinel oplog entry that will get sent to the destination side to let it know that the retryable write history is incomplete. Once it gets to the other side, it will realize that the transaction is committed and it will error out since it will be trying to process the oplog entry as if it was for a retryable write (specifically, it will trigger this assert via _registerUpdateCacheOnCommit callback registered by onMigrateCompletedOnPrimary).