Currently, retryable writes written during oplog catchup are compatible with change streams. Unfortunately, having retryable writes written before the migration starts will cause the migration to fail. The retryable write on the Donor will cause a change collection entry to be generated on the Donor. SERVER-70671 updated the Shard Merge protocol to copy all change collection entries to the Recipient. When we attempt to pre-fetch and apply retryable writes on the Recipient, we attempt to re-create the same change collection entry, which fails with a DuplicateKey error.

We'll need to ensure we're setting tid here, either via entry.getNss().tenantId() or entry.getTid(). Additionally, we should ensure we are setting tid in applyOps entries in the tenant migration recipient service and tenant oplog applier

We should ensure that both retryable writes and retryable FindAndModify work as part of this ticket.