- A primary node writes multiple same-node shard key updates.
- A second attempts to replicate, and is behind enough that it decides to batch apply instead of single apply.
When the secondary attempts to apply each statement separately, it will see that the document shard key is changing, and will uassert because the opCtx is not in a transaction. It wouldn't be in a transaction, because the batch apply has no transaction associated with itself. This individual uassert leads to an fassert from the replication code.
Add a check to !getOpCtx()->writesAreReplicated() in [this uassert here|https://github.com/mongodb/mongo/blob/406e1642a83d8b810bec41ad293c1b1c8a59a6dd/src/mongo/db/exec/update_stage.cpp#L929, so that we don't require the opCtx to have a transaction number if we are in a secondary node.