[SERVER-44151] Retryable write of findAndModify can return incorrect results when the 'fields' argument is specified Created: 22/Oct/19  Updated: 06/Dec/22  Resolved: 23/Oct/19

Status: Closed
Project: Core Server
Component/s: Querying, Sharding
Affects Version/s: 4.2.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ian Boros Assignee: Backlog - Query Team (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-31242 findAndModify no-op retry should resp... Open
Assigned Teams:
Query
Operating System: ALL
Participants:

 Description   

 

 

(function() {
const t = db.find_and_modify;
t.drop();
 
assert.commandWorked(t.insert({x: 1, y: 1, z: 1}));
 
let result = t.findAndModify({
    query: {x: 1},
    'new': false,
    update: {$set: {randomField: true}},
    fields: {x: 1, y: 1}
});
assert.eq(result.z, undefined);
})(); 

This test will succeed when run in the 'core' suite. When run in retryable_writes_jscore_passthrough which retries each write at least once, it will fail. This is because this code only fetches the preimage/postimage of the document from the oplog, but does not re-apply the 'fields' projection. This means that the entire pre-image/post-image will always be returned.



 Comments   
Comment by David Storch [ 22/Oct/19 ]

I think I've answered my own question by stumbling upon SERVER-31242 – a previous incarnation of this issue which was closed as "Won't Fix". I think it would make more sense to close this issue as a duplicate and re-open SERVER-31242, since the older ticket holds more context.

Comment by David Storch [ 22/Oct/19 ]

ian.boros, was this a regression in 4.2, or does it affect all versions which support retriable writes?

Comment by Ian Boros [ 22/Oct/19 ]

I don't know if this should go to query or sharding (as I believe they own retriable writes?). A potential fix would be to just re-apply the projection after fetching the document, in which case query would be the best team to do this.

Generated at Thu Feb 08 05:05:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.