This ticket addresses an issue where the MongoDB Server was allowing retrieval of the featureCompatibilityVersion (FCV) server parameter from a MongoS instance. Relying on this value when retrieved from a MongoS is incorrect, as it reflects the binary version of the process rather than the actual FCV of the cluster. This could lead to undefined behavior, with users mistakenly assuming the cluster is running under an incorrect FCV.

Starting with version 8.3.0, this command now returns an InvalidOptions error when run against a MongoS, preventing users from depending on this unreliable value.

Downstream attention is needed, as we have observed several tools that rely on this behavior. Please note that the documentation has always stated that running db.adminCommand(

{ getParameter: 1, featureCompatibilityVersion: 1 }

) on a MongoS is unsupported and results in undefined behavior.

To reliably retrieve the FCV, please use one of the following approaches:

1. From a MongoS, query the admin database directly:

use admin;
db.system.version.find(

{ _id: "featureCompatibilityVersion" }

)

2. Alternatively, run the getParameter command against a MongoD instance:

db.adminCommand(

{ getParameter: 1, featureCompatibilityVersion: 1 }

)

Please review your tools and update them accordingly. If you have any questions or need assistance, don't hesitate to reach out.

Thank you!

Description of Linked Ticket

In the previous ticket SERVER-100224, we resolved an issue where feature_compatibility_version.idl was incorrectly linked to mongos, allowing mongos to respond to the FCV getParameter command with the current binary version:

db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

This ticket aims to address a recurrence of that issue by removing the implicit linking of feature_compatibility_version.idl from mongos and ensuring that this incorrect library injection cannot happen again.