[SERVER-69244] $merge fails when session default read concern has been set to "majority" Created: 30/Aug/22  Updated: 30/Oct/23  Resolved: 05/May/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.11, 7.0.3, 6.0.12, 7.0.4

Type: Bug Priority: Major - P3
Reporter: Jess Balint Assignee: Jess Balint
Resolution: Fixed Votes: 0
Labels: auto-reverted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
Related
related to SERVER-47345 Fix causal consistency bug in $merge ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v7.0, v6.0, v5.0, v4.4
Sprint: QO 2022-08-22, QO 2022-09-19, QO 2022-10-03, QE 2022-10-17
Participants:
Case:
Linked BF Score: 162

 Description   

 Hi team,

User-visible impact as reported by the user (what is the user seeing):

The same aggregation with $merge works on a RS, but fails on a sharded cluster with error

 

MongoServerError: Command listIndexes does not support { readConcern: { level: "majority", provenance: "customDefault" } } :: caused by :: read concern not supported

MongoDB Version and Architecture:

Tested on v4.4.16 and v5.0.11 and v6.0.1

Steps to reproduce:

On a mongos, run the following:

use test
db.adminCommand({ "setDefaultRWConcern": 1, "defaultReadConcern":{ level: "majority"}})
db.test.drop()
db.test.insertOne({ a: 1 })
db.test.aggregate([{$merge:{ into: "coll2", on: "_id", whenMatched: "replace", whenNotMatched:"insert"}}])
// it doesn't matter whether the collection coll2 exists or not, the command fails with the same error

Expected:

The command should succeed

Actual result:

 

MongoServerError: Command listIndexes does not support { readConcern: { level: "majority", provenance: "customDefault" } } :: caused by :: read concern not supported

Note:

This issue does not happen on a RS.

The command would also succeed if the $merge stage only contains the collection name: {$merge:"coll2"}

Prioritized questions for the Server Team:

Please help confirm if this is a bug.



 Comments   
Comment by Githook User [ 27/Oct/23 ]

Author:

{'name': 'Jess Balint', 'email': 'jess.balint@mongodb.com', 'username': ''}

Message: SERVER-69244 - $merge fails when session default read concern has been set to "majority"

(cherry picked from commit 46b37b276a0d73f583ba2cee92175cb9156c028f)
Branch: v6.0
https://github.com/mongodb/mongo/commit/627b4d2b28505998a05306cd50eff265264ab842

Comment by Githook User [ 26/Oct/23 ]

Author:

{'name': 'Jess Balint', 'email': 'jess.balint@mongodb.com', 'username': ''}

Message: SERVER-69244 - $merge fails when session default read concern has been set to "majority"

(cherry picked from commit 46fbe5b380dfaa32ee22b137162d90db9debd23e)
Branch: v7.0
https://github.com/mongodb/mongo/commit/46b37b276a0d73f583ba2cee92175cb9156c028f

Comment by Githook User [ 22/Sep/23 ]

Author:

{'name': 'Jess Balint', 'email': 'jess.balint@mongodb.com', 'username': ''}

Message: SERVER-69244 - $merge fails when session default read concern has been set to "majority"

(cherry picked from commit 46fbe5b380dfaa32ee22b137162d90db9debd23e)
Branch: v6.0
https://github.com/mongodb/mongo/commit/4e377f9c35db5988d0ee4055d1564ba82129fd30

Comment by Steve Tarzia [ 13/Sep/23 ]

Yes, we should still do these, but we haven't started yet.  Thanks for the reminder, garaudy.etienne@mongodb.com!  We'll get a sense of the difficulty when we start moving backward through the versions.

Comment by Garaudy Etienne [ 13/Sep/23 ]

do we still plan on doing these backports? are they trivial?

Comment by Jess Balint [ 05/May/23 ]

The workaround is to avoid setting the default read concern.

Comment by Arun Kant [ 05/May/23 ]

Is there a workaround to address this issue ? We are seeing this issue with mongo 6.x enterprise version when using $merge ? We need this feature to populate another collection based from data in source collection. 

Source collection is sharded collection and target collection is not a sharded collection.

Please advise. 

Comment by Githook User [ 20/Apr/23 ]

Author:

{'name': 'Jess Balint', 'email': 'jbalint@gmail.com', 'username': 'jbalint'}

Message: SERVER-69244 - $merge fails when session default read concern has been set to "majority"
Branch: master
https://github.com/mongodb/mongo/commit/46fbe5b380dfaa32ee22b137162d90db9debd23e

Comment by xgen-buildbaron-user [ 19/Apr/23 ]

Ticket re-opened due to revert. sharding_multiversion began a consistent failure of jstests/sharding/query/merge_nondefault_read_concern.js

Comment by Githook User [ 19/Apr/23 ]

Author:

{'name': 'auto-revert-processor', 'email': 'dev-prod-dag@mongodb.com', 'username': ''}

Message: Revert "SERVER-69244 $merge fails when session default read concern has been set to "majority""

This reverts commit 2147b61844e1783f003ae5c42bee846f85b79105.
Branch: master
https://github.com/mongodb/mongo/commit/0c68dfca8d17e305ddd5c513c267f7fa7c7eaefe

Comment by Githook User [ 18/Apr/23 ]

Author:

{'name': 'Jess Balint', 'email': 'jbalint@gmail.com', 'username': 'jbalint'}

Message: SERVER-69244 $merge fails when session default read concern has been set to "majority"
Branch: master
https://github.com/mongodb/mongo/commit/2147b61844e1783f003ae5c42bee846f85b79105

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