[SERVER-79358] Dropping a collection in a replicaset should result in a no-op for 6.0 and below Created: 26/Jul/23  Updated: 27/Jul/23  Resolved: 27/Jul/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 5.0.19, 6.0.8
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Enrico Golfieri Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-43894 Make dropping a nonexistent collectio... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

After SERVER-43894 dropping a collection in a sharded cluster will result in a no-op.

However for a replica-set this is not the case for 6.0 and below.

Since we want to keep the user experience as uniform as possible, dropping a collection in replica-set should behave the same.

 

Currently on a sharded sharded cluster on 6.0
assert.commandWorked(db.runCommand({drop: "view"}));
uncaught exception: Error: command failed: {
"ok" : 0,
"errmsg" : "ns not found",
"code" : 26,
"codeName" : "NamespaceNotFound",
"$clusterTime" : {
"clusterTime" : Timestamp(1690370301, 7),
"signature" :

{ "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) }

},
"operationTime" : Timestamp(1690370301, 7)
} with original command request: {
"drop" : "view",
"lsid" :

{ "id" : UUID("396b8789-2a0d-4b8c-9114-56738b51c39f") }

,
"$clusterTime" : {
"clusterTime" : Timestamp(1690370301, 7),
"signature" :

{ "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) }

}
} on connection: connection to 127.0.0.1:27017 :
 

Currently on a replica-set in 6.0
assert.commandWorked(db.runCommand({drop: "view"}));
{
"info" : "database does not exist",
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1690370511, 1),
"signature" :

{ "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) }

},
"operationTime" : Timestamp(1690370511, 1)
}



 Comments   
Comment by Enrico Golfieri [ 27/Jul/23 ]

After talking with max.hirschhorn@mongodb.com we opted for discarding this ticket.

Having a command stop returning an error in a minor version upgrade seems it wouldn't actually effect the downstream users both internally and externally

Comment by Enrico Golfieri [ 26/Jul/23 ]

max.hirschhorn@mongodb.com we are currently back-porting an inconsistency in the errors reported by the renameCollection (BACKPORT-16594). This ticket is the result of this discussion

It's only about keeping the user experience as uniform as possible. If we shouldn't backport this ticket to 6.0 then also BACKPORT-16594 should not be merged

Comment by Max Hirschhorn [ 26/Jul/23 ]

I'm not sure we should change the behavior of existing commands in a stable release branch. enrico.golfieri@mongodb.com what motivated this request?

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