dropCollection() on timeseries yields inconsistent CollectionUUIDMismatch fields

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Execution
    • ALL
    • Hide 
      const randomCollName = "randColl"
assert.commandWorked(db.runCommand({create: randomCollName}));
const randomCollUUID = db.getCollectionInfos({name: randomCollName})[0].info.uuid;


const tsViewName = "tsViewNs";
db.createCollection(tsViewName, {timeseries: {timeField: "t", metaField: "m"}});
assert.commandWorked(db.runCommand({drop: tsViewName, collectionUUID: randomCollUUID}));

      If the above is stored as myrepro.js, the results differ pending on whether the environment is sharded or not. 

      It returns "expectedCollection: <buckets collection name>" when run on a replica set. 

      resmoke --suites=core myrepro.js

[js_test:myrepro] uncaught exception: Error: command failed: {
[js_test:myrepro]     "ok" : 0,
[js_test:myrepro]     "errmsg" : "Collection UUID does not match that specified",
[js_test:myrepro]     "code" : 361,
[js_test:myrepro]     "codeName" : "CollectionUUIDMismatch",
[js_test:myrepro]     "db" : "test",
[js_test:myrepro]     "collectionUUID" : UUID("ba53bd21-43c8-44d8-ae60-dc7ff0b4e14c"),
[js_test:myrepro]     "expectedCollection" : "system.buckets.tsViewNs",
[js_test:myrepro]     "actualCollection" : "randColl"
[js_test:myrepro] } with original command request: {
[js_test:myrepro]     "drop" : "tsViewNs",
[js_test:myrepro]     "collectionUUID" : UUID("ba53bd21-43c8-44d8-ae60-dc7ff0b4e14c"),
[js_test:myrepro]     "lsid" : {
[js_test:myrepro]         "id" : UUID("6e02d460-0738-4624-a2bc-c56f88c419d8")
[js_test:myrepro]     }
[js_test:myrepro] }

      but returns "expectedColleciton: <tsViewNs>" when run on a sharded topology 

       

      Show
      const randomCollName = "randColl" assert .commandWorked(db.runCommand({create: randomCollName})); const randomCollUUID = db.getCollectionInfos({name: randomCollName})[0].info.uuid; const tsViewName = "tsViewNs" ; db.createCollection(tsViewName, {timeseries: {timeField: "t" , metaField: "m" }}); assert .commandWorked(db.runCommand({drop: tsViewName, collectionUUID: randomCollUUID})); If the above is stored as myrepro.js, the results differ pending on whether the environment is sharded or not.  It returns "expectedCollection: <buckets collection name>" when run on a replica set.  resmoke --suites=core myrepro.js [js_test:myrepro] uncaught exception: Error: command failed: { [js_test:myrepro]     "ok" : 0, [js_test:myrepro]     "errmsg" : "Collection UUID does not match that specified" , [js_test:myrepro]     "code" : 361, [js_test:myrepro]     "codeName" : "CollectionUUIDMismatch" , [js_test:myrepro]     "db" : "test" , [js_test:myrepro]     "collectionUUID" : UUID( "ba53bd21-43c8-44d8-ae60-dc7ff0b4e14c" ), [js_test:myrepro]     "expectedCollection" : "system.buckets.tsViewNs" , [js_test:myrepro]     "actualCollection" : "randColl" [js_test:myrepro] } with original command request: { [js_test:myrepro]     "drop" : "tsViewNs" , [js_test:myrepro]     "collectionUUID" : UUID( "ba53bd21-43c8-44d8-ae60-dc7ff0b4e14c" ), [js_test:myrepro]     "lsid" : { [js_test:myrepro]         "id" : UUID( "6e02d460-0738-4624-a2bc-c56f88c419d8" ) [js_test:myrepro]     } [js_test:myrepro] } but returns "expectedColleciton: <tsViewNs>" when run on a sharded topology   
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      dropCollection() on a timeseries view namespace with a mismatched collectionUUID returns CollectionUUIDMismatch.

      However, when run on a replica set, we get "'expectedCollection': <timeseries buckets namespace>". When run through the mongos, we get "'expectedCollection': <timeseries view ns>".

              Assignee:
              [DO NOT USE] Backlog - Storage Execution Team
              Reporter:
              Haley Connelly
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: