[SERVER-64751] ApplyOpsCommandInfo::areOpsCrudOnly() considers "n" ops as crud Created: 21/Mar/22 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Cheahuychou Mao | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | tech-debt-repl | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
ApplyOpsCommandInfo::areOpsCrudOnly() currently considers "n" ops as crud ops although OplogEntry::isCrudOpType() doesn't consider them as crud ops. This ticket is to determine if we should reconcile these different definitions since they can lead to unexpected errors. For example, the ReshardingOplogPreparer uses areOpsCrudOnly() to validate each applyOps oplog entry and isCrudOpType() to validate each individual applyOps operation. So if there is an applyOps oplog entry with a noop operation, the ReshardingOplogPreparer would hit this invariant here.
|
| Comments |
| Comment by Judah Schvimer [ 21/Mar/22 ] |
|
I think an alternative would be to remove atomic applyOps ( |