[SERVER-67885] shardCollection with a mismatched UUID on a capped collection will fail first with InvalidOptions Created: 07/Jul/22  Updated: 29/Oct/23  Resolved: 02/Aug/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.1, 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Xuerui Fa Assignee: Fausto Leyva (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v6.0
Steps To Reproduce:

(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();
})();

Sprint: Execution Team 2022-08-08
Participants:
Linked BF Score: 150

 Description   

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!



 Comments   
Comment by Githook User [ 04/Aug/22 ]

Author:

{'name': 'Faustoleyva54', 'email': 'fausto.leyva@mongodb.com', 'username': 'Faustoleyva54'}

Message: SERVER-67885 shardCollection with a mismatched UUID on a capped collection will fail first with InvalidOptions
Branch: v6.0
https://github.com/mongodb/mongo/commit/c500300c081eab9bbf42dccff05a0588cfc59821

Generated at Thu Feb 08 06:09:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.