Running sub-queries with the same OperationContext can lead to unexpected behavior upon retrying

    • 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

            Assignee:
            Ronald Steinke
            Reporter:
            Damian Wasilewicz
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: