[SERVER-32346] When applying applyOps commands during initialSync, do not override alwaysUpsert flag Created: 14/Dec/17  Updated: 27/Oct/23  Resolved: 09/Dec/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Matthew Russotto Assignee: A. Jesse Jiryu Davis
Resolution: Gone away Votes: 0
Labels: initialSync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32913 Parallelize application of applyOps o... Closed
is related to SERVER-21700 Do not relax constraints during stead... Closed
Operating System: ALL
Sprint: Repl 2018-01-15, Repl 2019-10-07, Repl 2019-10-21, Repl 2019-12-16
Participants:
Case:

 Description   

Right now if we have an applyOps command with an 'alwaysUpsert: false' field, it will be applied with 'alwaysUpsert: false' both during steady state replication and in initial sync. This has the same idempotency problem as applying ordinary updates during initial sync, which is that the updated document may not be there because it might have been deleted on the sync source after the oplog entry. So we should ignore the applyOps alwaysUpsert field during initial sync.



 Comments   
Comment by A. Jesse Jiryu Davis [ 09/Dec/19 ]

No, I can't find any evidence of this in our current code base so I think it's been fixed.

Comment by Judah Schvimer [ 12/Sep/19 ]

jesse, is this still a problem?

Comment by Spencer Brody (Inactive) [ 08/Feb/18 ]

Without this fix, initial sync fails unnecessarily.

Comment by Gregory McKeon (Inactive) [ 26/Jan/18 ]

This may fall out of SERVER-32913, deferring this for now.

Comment by Matthew Russotto [ 19/Jan/18 ]

This is not quite right. For initial sync, we need to re-fetch the document; upsert is not sufficient. For initial command application we want to respect the flag. For steady-state replication we want to upsert for idempotency after a rollback.

Generated at Thu Feb 08 04:29:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.