-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: None
-
Query Execution
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Summary
jstests/core/query/query\_settings/query\_settings\_knob\_validation\_pbt.js
failed 15 times across 4 burn-in variants (burn_in:config_fuzzer_
{replica\_sets,sharding}_jscore_passthrough, all burn-in iterations) on patch build 6ac7a32cc16e160007d31b64, with:
unexpected knob value for 'queryStatsSampleRate': expected 1, got 0.0001 / 0.1 / 0
always on the persisted-setQuerySettings check (the knob source assert passed: source reported
{"querySettings"} while the value was stale).h2. Evidence
* The PBT reuses a single query shape for all 50 parity cases. A case whose model value for the knob is 0 ran ~25 minutes before a later case (value 1) whose persisted-settings explain served the stale 0 with source {"querySettings"}
- confirmed by a local reproduction (replica_sets_jscore_passthrough + FuzzRuntimeParameters hook + fuzzMongodConfigs).
- Static analysis (exhaustive): only two writers stamp KnobSource::kQuerySettings, both value-fed from the operation's resolved QuerySettings; the snapshot cache (incl. thread-local versioning) is exonerated; no path materializes global parameter values into a QuerySettings.
- On CI, the stale values (0.0001, 0.1) were not generated by the model in the failing runs - they match the config fuzzer's choices for internalQueryStatsSampleRate ([0, 0.0001, 0.1, 1.0], set via setParameter every ~10s on all nodes). Provenance of those values is unresolved.
- Server-side instrumentation (QSRESOLVE/QSINSTALL/QSCACHE/QSEXPLAIN) over 8 further rounds observed no stale resolution and no out-of-order cluster parameter install - the race appears sensitive to timing perturbation.
Suspected area
Query settings resolution staleness under concurrent cluster-parameter churn - related to the non-monotonic clusterParameterTime install path (query_settings_manager.cpp setVersionedQueryShapeConfigurations deliberately does not enforce monotonic time; QuerySettingsClusterParameter::set only skips on equal time, so an older snapshot can install and revert newer settings). See TODO SERVER-106885.
Mitigation applied
The PBT's persisted-settings check is now eventually-consistent (assert.soonNoExcept around the explain), matching the $querySettings verification semantics already used by the test.
Notes
- Not introduced by SERVER-134528 (which only added the knob to the PBT model, exposing the pre-existing staleness), but the exposure correlates with the config fuzzer also fuzzing this specific parameter.
- PR: https://github.com/10gen/mongo/pull/62730