[SERVER-44289] Retryable writes that change shard key value and owning shard that include write concern fail with InvalidOptions Created: 28/Oct/19  Updated: 29/Oct/23  Resolved: 13/Nov/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.2.2, 4.3.2

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Kevin Pulo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-43712 Use RWCDefaults for incoming requests... Closed
is related to SERVER-44593 In retryable write that changes shard... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

(function() {
"use strict";
 
const dbName = "test";
const collName = "foo";
const ns = dbName + '.' + collName;
 
const st = new ShardingTest({shards: 2, config: 1});
 
assert.commandWorked(st.s.adminCommand({enableSharding: dbName}));
st.ensurePrimaryShard(dbName, st.shard0.shardName);
assert.commandWorked(st.s.adminCommand({shardCollection: ns, key: {skey: 1}}));
 
assert.commandWorked(st.s.adminCommand({split: ns, middle: {skey: 0}}));
assert.commandWorked(st.s.adminCommand({moveChunk: ns, find: {skey: 0}, to: st.shard1.shardName}));
assert.commandWorked(st.s.getDB(dbName)[collName].insert({skey: 10}));
 
const sessionDB = st.s.startSession({retryWrites: true}).getDatabase(dbName);
 
assert.writeOK(sessionDB[collName].update({skey: 10}, {$set: {skey: -10}}));
sessionDB[collName].findAndModify({query: {skey: -10}, update: {$set: {skey: 10}}});
 
// Both operations below fail with InvalidOptions.
assert.writeOK(sessionDB[collName].update({skey: 10}, {$set: {skey: -10}}, {writeConcern: {w: 1}}));
sessionDB[collName].findAndModify({query: {skey: -10}, update: {$set: {skey: 10}}, writeConcern: {w: 1}});
 
st.stop();
})();

Sprint: Sharding 2019-11-18
Participants:

 Description   

When a retryable write would change a document's shard key value and cause that document to move chunks, mongos will internally use a transaction to atomically delete and insert the document with the new value. As part of this, mongos will re-run the original command received from the user in a transaction (e.g. in findAndModify), which will fail if the command included a write concern, because write concern is not allowed in a transaction before commit/abort.

Instead the write concern should only be applied at the commit/abort of the internal transaction.



 Comments   
Comment by Githook User [ 13/Nov/19 ]

Author:

{'username': 'devkev', 'email': 'kevin.pulo@mongodb.com', 'name': 'Kevin Pulo'}

Message: SERVER-44289 permit writeConcern on retryable writes that move doc onto another shard

(cherry picked from commit 9861e230bcb9bb37ed1cbb504ed4ff177a0300da)
(partial cherry pick from commit 81238fa87afbe52a9658547f63c79fac126862f1)
Branch: v4.2
https://github.com/mongodb/mongo/commit/3bc3aa7a96971423f428bd9a1e1df4f110ea730b

Comment by Githook User [ 13/Nov/19 ]

Author:

{'username': 'devkev', 'email': 'kevin.pulo@mongodb.com', 'name': 'Kevin Pulo'}

Message: SERVER-44289 permit writeConcern on retryable writes that move doc onto another shard
Branch: master
https://github.com/mongodb/mongo/commit/9861e230bcb9bb37ed1cbb504ed4ff177a0300da

Comment by Kevin Pulo [ 10/Nov/19 ]

Confirmed that 81238fa87af on SERVER-43712 fixes the problem in master.

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