[SERVER-42752] setFeatureCompatibilityVersion command can return before it applied the changes Created: 09/Aug/19  Updated: 23/Aug/19  Resolved: 23/Aug/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 4.2.0-rc8
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Misha Tyulenev
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Operating System: ALL
Steps To Reproduce:

this[ lobster |https://logkeeper.mongodb.org/lobster/build/85197e12c3faddbd254675e593b18daa/test/5d336884be07c4080101133e#bookmarks=0%2C2147%2C2187%2C2282%2C2984]has marked the process c20523 is not updated at the moment mongos RSM targets it.

Sprint: Sharding 2019-08-26, Sharding 2019-09-09
Participants:
Linked BF Score: 22

 Description   

setFeatureCompatibilityVersion command can return before all the nodes in config cluster are downgraded as this is tied to writing the featureCompatibilityVersion document.
The follow-up attempt to connect to all config shard nodes can fail the mongos when it attempts to refresh shardRegistry



 Comments   
Comment by Misha Tyulenev [ 23/Aug/19 ]

The possible fix for this issue is to use a writeConcern that guarantees ack from all configserver nodes instead of Majority. 
This seems to be unreasonable.
The alternative is to remove this fassert: https://github.com/mongodb/mongo/blob/v4.0/src/mongo/client/dbclient_connection.cpp#L278

But its already not in 4.2, hence the only possible issue is a transient failure during 4.0->4.2 upgrade.  

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