ISSUE DESCRIPTION AND IMPACT

When connecting directly to shard nodes instead of through mongos (including during a replica set promotion to sharded cluster), cluster-wide default read/write concerns may not be honored, causing writes to use {w: 1} instead of configured concerns, potentially losing acknowledged writes if rollback occurs.

DIAGNOSIS AND AFFECTED VERSIONS

Any direct shard operations without explicit read/write concerns are affected on the following MongoDB versions:

• 5.0.0 - 5.0.32
• 6.0.0 - 6.0.28
• 7.0.0 - 7.0.31
• 8.0.0 - 8.0.19
• 8.2.0 - 8.2.3

REMEDIATION AND WORKAROUNDS

Before promoting a replica set to a sharded cluster

• Upgrade to the latest MongoDB patch version
• If upgrading is not immediately possible, take one of the following precautions for future promotions:
• Specify explicit read and write concerns (e.g., {w: "majority"}) in your connection string, or

• Stop all application traffic before beginning the promotion

After promotion

• Update your application connection string to use mongos
• Restart your application to ensure it connects via mongos

—-----------------------------------------------------

Original description

Our default write concern system is only applied to replica set nodes under the assumption that the mongoS will specify the write concern within a sharded cluster. However, this means that during promotion to sharded when a replica set has been restarted with --shardsvr or --configsvr but connections haven't been switched to the mongos, the default write concern is not applied and thus we use the default constructed write concern options which is w:1.

This also applies to read concern though is less visible since the implicit default is the same as the normal default (local). But if the user has a cluster wide read concern default set, we will not honor it during the promotion (or via direct connections)