[SERVER-32934] Full document replacement can change type of _id Created: 26/Jan/18 Updated: 27/Oct/23 Resolved: 23/Feb/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Benety Goh | Assignee: | Backlog - Query Execution |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | query-44-grooming, storch | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||||||
| Steps To Reproduce: |
|
||||||||||||||||
| Sprint: | Query 2018-02-12, QO 2023-02-20 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Full document replacement can change the type of immutable fields in 3.6. It cannot change the value. Modifier-style updates cannot change the type. |
| Comments |
| Comment by David Storch [ 23/Feb/23 ] | ||||||||||||||||||||||||||||
|
Closing as "Gone Away" per Charlie's recommendation above. | ||||||||||||||||||||||||||||
| Comment by Charlie Swanson [ 16/Feb/23 ] | ||||||||||||||||||||||||||||
|
Yeah I think this is a non-issue. I checked with max.hirschhorn@mongodb.com's example to be doubly sure. But it seems to replicate OK and show the same post-image on the secondaries. This makes sense because the query system should treat them as equivalent for find-by-_id, and then they will apply the same update logic to end up with the same post-image. I think this was probably an upgrade/downgrade bug from 3.4 to 3.6 where this type of update on a 3.6 primary would replicate to a 3.4 secondary and result in a differently-typed _id between the two nodes. But that ship has long sailed. I'm going to put this back into "Needs Scheduling" for attention, but my recommendation would be to close this as either "Gone Away" (upgrade/downgrade concern is in the past) or "Won't Fix" or something like that. | ||||||||||||||||||||||||||||
| Comment by Max Hirschhorn [ 26/Jan/23 ] | ||||||||||||||||||||||||||||
|
I noticed that pipeline updates also allow changing the _id value to an equivalent but not binary-equal value (e.g. a different BSON type). Flagging this for Needs Scheduling to have someone from the Query team take a look and evaluate whether there are any deeper concerns (e.g. potential for data inconsistency) about the current behavior. I do suspect there won't be any concerns.
| ||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 22/Feb/18 ] | ||||||||||||||||||||||||||||
|
Making it an error when type is different in replacement document (for _id) would definitely be a backwards breaking change. | ||||||||||||||||||||||||||||
| Comment by Justin Seyster [ 17/Feb/18 ] | ||||||||||||||||||||||||||||
|
Both the 3.4 and 3.6 update path use compareWithBSONElement() to compare the old and new _id values, which considers equal values to be equal even when their types are different. In the 3.4 code path, object replacement works by stripping everything except the _id element out of the input document and then repopulating it with the elements from the replacement document (again, except for the _id element). In the new update system, object replacement always strips the entire document including _id, and always copies _id from the replacement document (unless the replacement document doesn't have _id). We should probably explicitly check the type of the old and new field when validating an update to prevent this problem. Would something like this be considered a backwards breaking change? A little more worrying, the check in 3.6 to ensure _id does not change is also used to check other immutable paths, so it should be possible to mutate the shard key type as well. This problem probably also existed in 3.4. | ||||||||||||||||||||||||||||
| Comment by David Storch [ 30/Jan/18 ] | ||||||||||||||||||||||||||||
|
justin.seyster@mongodb.com, I'm assigning this to you in order to investigate. Once you have an understanding of what's going on, you can put this back on the Needs Triage, Backlog - Query Team queue with a comment explaining the root cause. | ||||||||||||||||||||||||||||
| Comment by Tess Avitabile (Inactive) [ 29/Jan/18 ] | ||||||||||||||||||||||||||||
|
Yes, this looks like a bug in the update system. Assigning this to the Query team. |