-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Sharding
-
None
-
Fully Compatible
-
ALL
-
Sharding 2019-05-06
Background:
- 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.
Issue:
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.
Fix:
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.