Concurrent DDL operations during insert on viewless timeseries lead to insertion of non-bucket documents

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 5.0 Required, 8.2.0-rc0
    • Affects Version/s: 8.2.0-rc0
    • Component/s: None
    • None
    • Storage Execution
    • ALL
    • Hide 
      resmoke.py --runAllFeatureFlagTests --force-excluded-tests --repeatTests=10 --mongodSetParameters="{logComponentVerbosity: {replication: 1}}" --suite=concurrency_replication_viewless_timeseries jstests/concurrency/fsm_workloads/timeseries/timeseries_create_indexes.js
      Show
      resmoke.py --runAllFeatureFlagTests --force-excluded-tests --repeatTests=10 --mongodSetParameters="{logComponentVerbosity: {replication: 1}}" --suite=concurrency_replication_viewless_timeseries jstests/concurrency/fsm_workloads/timeseries/timeseries_create_indexes.js
    • Storage Execution 2025-06-23
    • None
    • 3
    • TBD
    • None
    • None
    • None
    • None
    • None
    • None
    • 0

      In SERVER-101952 we added a new timeseries/create_indexes.js FSM test that preform insert operations on a collection while the collection is being repeatedly dropped and recreated as both timeseries and normal collection.

      When this test runs on viewless timeseries suite that have the `createViewlessTimeseriesCollections` feature flag enabled, we observed that the collection can end-up with mixed documents format. The collection will contain both bucket documents and normal documents.

      example

      [
  {
    "_id": {
      "$oid": "681e33dcaf015752e8f31a2c"
    },
    "control": {
      "version": 2,
      "min": {
        "_id": {
          "$oid": "681e33dff858542ab53dbf6a"
        },
        "measurement": "measurement",
        "time": {
          "$date": "2025-05-09T16:57:00Z"
        }
      },
      "max": {
        "_id": {
          "$oid": "681e33dff858542ab53dbf70"
        },
        "measurement": "measurement",
        "time": {
          "$date": "2025-05-09T16:57:03.732Z"
        }
      },
      "count": 3
    },
    "data": {
      "time": {
        "$binary": {
          "base64": "CQClofq1lgEAAIBNAgAAWAEAAAA=",
          "subType": "07"
        }
      },
      "_id": {
        "$binary": {
          "base64": "BwBoHjPf+FhUKrU9v2qATQAAABAAAAAA",
          "subType": "07"
        }
      },
      "measurement": {
        "$binary": {
          "base64": "AgAMAAAAbWVhc3VyZW1lbnQAgA0AAAAAAAAAAA==",
          "subType": "07"
        }
      }
    }
  },
  {
    "_id": {
      "$oid": "681e33dff858542ab53dbf64"
    },
    "measurement": "measurement",
    "time": {
      "$date": "2025-05-09T16:57:03.571Z"
    }
  },
  {
    "_id": {
      "$oid": "681e33dff858542ab53dbf66"
    },
    "measurement": "measurement",
    "time": {
      "$date": "2025-05-09T16:57:03.574Z"
    }
  }
]

      My suspect is that the write path does not properly handle concurrent transformation to the underlying collection from timeseries to normal collection or vice versa.

      How to reproduce

      • Run jstests/concurrency/fsm_workloads/timeseries/timeseries_create_indexes.js test in the concurrency_replication_viewless_timeseries suite.
      • The test will eventually hit this tassert

            Assignee:
            Damian Wasilewicz
            Reporter:
            Tommaso Tocci
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: