Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-102050

Some time-series tests implicitly rely on measurement insertion order for unordered inserts when checking bucket catalog stats

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Execution
    • ALL
    • Storage Execution 2025-03-31
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      An example of this can be found in timeseries_serverStatus.js.

      Specifically, this scenario inserts two measurements, one that is far in the past and one that has the current time as its measurement. The measurements are inserted in [new, old] order. There is an existing bucket A that is eligible to take the current measurement but not the old one.

      In the old path, we would try to insert the new measurement first and then rollover the second bucket with timeBackward, causing it to be archived when we go to finish it's batch.

      In the new path, we sort the measurements, so the old measurement gets inserted first. It archives Bucket A, and allocates a new Bucket B to accept the insert. Then, when we go to insert the current measurement, Bucket B gets rolled over with time forward.

      Since time forward is a softClose rollover action, when we go to finish the batch for this bucket we also close it. This leads to the assertion that 'numBuckets' == 2 to fail in our new write path.

            Assignee:
            damian.wasilewicz@mongodb.com Damian Wasilewicz
            Reporter:
            damian.wasilewicz@mongodb.com Damian Wasilewicz
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:
              None
              None
              None
              None