-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
Sharding 2021-01-25, Sharding 2021-02-22, Sharding 2021-03-08, Sharding 2021-03-22
If a write does not generate an oplog entry, it must be because any earlier writes this write depends on is already reflected in the data (lingzhi.deng , could you confirm?).
This means any writes this write depends on must have been assigned an OpTime earlier than blockTimestamp, at least on this primary's branch of history.
If the write came with w:majority, the write will wait for the system last OpTime to be majority committed, which must include the blockTimestamp. So, if the migration commits, the write is guaranteed to be reflected on the recipient.
If the write came with w < majority, the write is not guaranteed to be reflected in the database anyway, so it is ok if it is not reflected on the recipient.
So, there should be no need to do anything special for such writes, though jack.mulrow, it may be good to confirm that causal consistency will be respected for such writes.