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

create fails on already-sharded time-series collection

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.2.0-rc0
    • Affects Version/s: 7.0.1
    • Component/s: None
    • None
    • Storage Execution
    • Fully Compatible
    • ALL
    • Hide

      Run the above script, e.g., with `mongosh`.

      Show
      Run the above script, e.g., with `mongosh`.
    • Execution NAMR Team 2023-10-02, Execution NAMR Team 2023-10-16

      The following fails for me every time on 7.1.0-alpha0-201-g1eb2c72:

      db = db.getSiblingDB("mytest")
      
      db.dropDatabase()
      
      db.createCollection(
          "weather",
          {
              timeseries: {
                  timeField: "mytimefield",
              },
          },
      )
      
      db.getSiblingDB("admin").runCommand(
          {
              shardCollection: db.getName() + `.weather`,
              key: {
                  mytimefield: 1,
              },
          },
      )
      
      db.createCollection(
          "weather",
          {
              timeseries: {
                  timeField: "mytimefield",
              },
          },
      )
      

      The failure is:

      MongoServerError: got stale shardVersion response from shard src-sh02 at host localhost:28022 :: caused by :: timestamp mismatch detected for TestE2EIntegrationTestSuite_TestTimeSeries_Sha-8120c373cd712241.system.buckets.weather
      

      In v7.0.1 the error is less serious-looking:

      MongoServerError: namespace mytest.weather already exists, but is a view on mytest.system.buckets.weather rather than mytest.
      

      In v6.0.9 the error also looks wrong:

      MongoServerError: ns: mytest.weather already exists with different options: { timeseries: { timeField: "mytimefield", granularity: "seconds", bucketMaxSpanSeconds: 3600 } }
      

      I would expect there to be no error since I’m just creating the existing collection. The 7.1.0 error looks worst, followed by 6.0.9, then 7.0.1.

            Assignee:
            gregory.noma@mongodb.com Gregory Noma
            Reporter:
            felipe.gasper@mongodb.com Felipe Gasper
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: