[SERVER-76926] Unify insert and {upsert: true} insert behavior for $setOnInsert: Timestamp(0,0) Created: 08/May/23  Updated: 11/Aug/23  Resolved: 14/Jun/23

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

Type: Task Priority: Major - P3
Reporter: Sanika Phanse (Inactive) Assignee: Backlog - Query Execution
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
Assigned Teams:
Query Execution
Participants:

 Description   

Upon inserting a document with { $setOnInsert

{ 'a' : Timestamp(0,0) }

, the timestamp is overwritten to reflect the operational timestamp here. However, an update with

{upsert: true}

that specifies $setOnInsert

{ 'a' : Timestamp(0,0) }

preserves the value Timestamp(0,0) in the upserted document. This is inconsistent behavior between two types of inserts.

I would recommend unifying this behavior.

This ticket is relevant for the updateOneWithoutShardKey project as upserts are converted to inserts on mongos. So, while the user behavior would've originally expected Timestamp(0,0) to remain, it now reflects the operational timestamp.



 Comments   
Comment by Rohan Sharan [ 11/Aug/23 ]

How difficult would this be to fix? We're seeing inconsistencies in mongosync because of this. It would not be ideal to add a limitation that mongosync can't support syncing documents with a field of timestamp(0, 0).

Comment by Kyle Suarez [ 14/Jun/23 ]

After in a discussion in the Query Execution triage meeting, while we acknowledge this is an inconsistency in behavior, we don't think that this is worth fixing because it represents a corner case that almost no customer is going to encounter in practice. We're going to close this issue unless there's any actual customer impact.

Generated at Thu Feb 08 06:34:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.