When a non-strict cluster parameter is defined as a struct and a user misspells a field that has a default value, the setClusterParameter command incorrectly returns OK and silently resets that field to its default value instead of rejecting the request.

Example

Consider internalSearchOptions, which is defined as a non-strict struct, and where oversubscriptionFactor has a default value in the IDL.

The following command succeeds and sets back oversubscriptionFactor to its default value, not to 2.5. Note that 'oversubscriptionFacto' is misspelled (s is missing)

setClusterParameter: {
   internalSearchOptions: {
      oversubscriptionFacto: Double(2.5),
      batchSizeGrowthFactor: Double(4)
  }
}

These are the cluster parameters that are currently affected:

• fleCompactionOptions
• fleAllowTotalTagOverheadToExceedBSONLimit
• fleDisableSubstringPreviewParameterLimits
• internalSearchOptions

Solution

To address this issue, we are enabling strict parsing for all cluster parameters.

The original motivation for non-strict cluster parameters was likely to ease backward compatibility when adding or deprecating fields. However, upgrade/downgrade transitions can still be handled safely with strict IDL parsing by following this pattern:

Adding a new field

• The new field may only be set when the cluster is running the newest FCV.
  This ensures that in mixed-binary scenarios (where some binaries are not yet aware of the field), the field cannot be set.
• On downgrade, if the field is present, the downgrade should fail with CannotDowngrade until the field is manually removed.

Deprecating a field.

• Deprecation should happen in two steps:
     - First, mark the field as optional and keep it until the next major release branches.
     - Then, remove the field when the following major release branches.
• While deprecated, the field should not be settable on the newest FCV, preventing new usage while allowing existing configurations to phase out safely.