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

shardCollection with a mismatched UUID on a capped collection will fail first with InvalidOptions

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.0.1, 6.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • v6.0
    • Hide 
      (function() {
"use strict";

const st = new ShardingTest({shards: 2, mongos: 1});

const dbName = "testDB";
const collName = "cappedColl";
const ns = dbName + "." + collName;

// Create capped collection.
assert.commandWorked(st.s.getDB(dbName).createCollection(collName, {capped: true, size: 1024}));

st.s.adminCommand({enableSharding: dbName});
st.ensurePrimaryShard(dbName, st.shard0.shardName);
// Shard collection with nonsensical UUID.
// This will fail with InvalidOptions instead of CollectionUUIDMismatch
assert.commandWorked(st.s.adminCommand({shardCollection: ns, collectionUUID: UUID("81fd5473-1747-4c9d-8743-f10642b3bb99"), key: {key: 1}}));

st.stop();
})();
      Show
      (function() { "use strict"; const st = new ShardingTest({shards: 2, mongos: 1}); const dbName = "testDB"; const collName = "cappedColl"; const ns = dbName + "." + collName; // Create capped collection. assert.commandWorked(st.s.getDB(dbName).createCollection(collName, {capped: true, size: 1024})); st.s.adminCommand({enableSharding: dbName}); st.ensurePrimaryShard(dbName, st.shard0.shardName); // Shard collection with nonsensical UUID. // This will fail with InvalidOptions instead of CollectionUUIDMismatch assert.commandWorked(st.s.adminCommand({shardCollection: ns, collectionUUID: UUID("81fd5473-1747-4c9d-8743-f10642b3bb99"), key: {key: 1}})); st.stop(); })();
    • Execution Team 2022-08-08
    • 150

      This issue was discovered in C2C:

      When sharding a collection with UUID specified, it seems we first check if the collection is capped, then we see if there is a UUID mismatch. As a result, this situation may occur:

      1. Create a collection, shard it, then drop it, all with UUID1
      2. Create a collection with the same name but as a capped collection. It now has UUID2
      3. Kill the replicator and restart it. It begins reapplying events in CEA, starting from the shardCollection with UUID1
      4. The shardCollection will see that the coll exists with UUID2. We expect it to fail with CollectionUUIDMIsmatch, but it seems server will first check that it is not a capped collection, see that it is, and then return InvalidOptions – can't shard a capped collection, instead of CollectionUUIDMismatch.

      SInce mongosync doesn't handle InvalidOptions, it will crash in this situation. Ideally, it seems server should always first check the collection UUID. If there is not a mismatch, then we can proceed with the rest of the validation.

      Attached a server-only repro of this issue!

            Assignee:
            fausto.leyva@mongodb.com Fausto Leyva (Inactive)
            Reporter:
            xuerui.fa@mongodb.com Xuerui Fa
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: