Info

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.

Top User Comments

Steps to Reproduce