The heuristic to restore extended range timestamps can fail to restore correctly in some cases

XMLWordPrintableJSON

    • Storage Execution
    • Fully Compatible
    • ALL
    • Hide

      The following steps will reproduce the issue.  Note that timestamps close to unix epoch 32-bit time with 1-second resolution generally do pass the heuristic.  Extreme timestamps like the one shown here are from > year 6000 and triggers a failure. 

      
// Start Mongod in another shell
> db.createCollection("ts", {timeseries:{timeField:"t"}})
> db.ts.insert({t: new Date(137591838720000), x: "yz"})
> db.ts.validate() // success
// Stop Mongod in the other shell
// Restart Mongod in the other shell
> db.ts.validate() // fails with unsupported extended range
      Show
      The following steps will reproduce the issue.  Note that timestamps close to unix epoch 32-bit time with 1-second resolution generally do pass the heuristic.  Extreme timestamps like the one shown here are from > year 6000 and triggers a failure.  // Start Mongod in another shell > db.createCollection( "ts" , {timeseries:{timeField: "t" }}) > db.ts.insert({t: new Date(137591838720000), x: "yz" }) > db.ts.validate() // success // Stop Mongod in the other shell // Restart Mongod in the other shell > db.ts.validate() // fails with unsupported extended range
    • Storage Execution 2026-03-02, Storage Execution 2026-03-16, Storage Execution 2026-03-30
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      During startup, a heuristic determines if a collection requires extended range suppport by checking a key bit in the `_id` field.  In some cases, this heuristic will fail to accurately determine the need for this flag. 

            Assignee:
            Benjamin Pearce
            Reporter:
            Benjamin Pearce
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: