-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Server Programmability
-
ALL
-
Storage Execution 2025-09-01
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Certain operations will perform queries within the larger operation that may "pollute" the operationContext. An example of this can be found in the following
1) We perform an insert request into a time-series collection here
2) We perform queries through DBClient to find buckets to reopen here and here
3) We call in to DBClient and re-use the same OperationContext here.
4) While processing the request we set the rawDataOperation value for the request to true here
5) At this point, we may encounter an error that causes us to retry the request which would throw in the service entry point shard role here. In the example provided here, I've seen this happen in fcv_upgrade_downgrade suites because setFcv now takes the critical section following SERVER-103711
6) We call back in to retry the insert request, but now the rawDataOperation value is still true since it was not reset, and we try to insert the measurements into the buckets collection as if it were a raw data operation.
Other commands that use nested queries/operations that reuse the same operationContext will also be susceptible to this
- is related to
-
SERVER-103711 Replace setter methods from DatabaseShardingRuntime with a new dedicated class
-
- Closed
-
- related to
-
SERVER-77508 ReadConcern isn't propagated to DBDirectClient
-
- Closed
-
-
SERVER-110295 Temporarily exclude timeseries_internal_bounded_sort.js and bucket_unpacking_with_sort_extended_range.js from fcv_upgrade_downgrade_sharding_jscore_passthrough suite
-
- Closed
-