[SERVER-43894] Make dropping a nonexistent collection a noop Created: 08/Oct/19  Updated: 29/Oct/23  Resolved: 09/Feb/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.0.0-rc0

Type: Bug Priority: Minor - P4
Reporter: Oleg Pudeyev (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-32550 Drop of a non-existing collection on ... Closed
Problem/Incident
causes VSCODE-461 Server 7.0 allows dropping nonexisten... Open
Related
related to SERVER-79358 Dropping a collection in a replicaset... Closed
related to SERVER-55145 Make dropping a nonexistent database ... Closed
related to DRIVERS-2118 Create collection and database manage... Backlog
is related to SERVER-73934 Remove commandWorkedOrFailedWithCode(... Closed
is related to SERVER-41365 Improve unhelpful error "ns not found" Closed
is related to NODE-5059 CRUD tests fail on latest because dro... Closed
Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2023-02-20, Execution Team 2023-02-06
Participants:
Linked BF Score: 100

 Description   

Currently dropping a nonexistent collection is an error (SERVER-41365). I think that if the user wants to drop the collection and it happens to already not exist, the outcome is successful. Thus dropping a nonexistent collection should do nothing and return success to the client.



 Comments   
Comment by Githook User [ 14/Feb/23 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: fix(shell-api): adjust .drop() return value for server changes (#1406)

See SERVER-43894, the server now returns no error when dropping
non-existent collections.
Branch: 1358-dev
https://github.com/mongodb-js/mongosh/commit/0725693d70f1811fc9bf4059f3fa292b57e8f650

Comment by Githook User [ 10/Feb/23 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: fix(shell-api): adjust .drop() return value for server changes (#1406)

See SERVER-43894, the server now returns no error when dropping
non-existent collections.
Branch: main
https://github.com/mongodb-js/mongosh/commit/0725693d70f1811fc9bf4059f3fa292b57e8f650

Comment by Githook User [ 09/Feb/23 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: fix(shell-api): adjust .drop() return value for server changes

See SERVER-43894, the server now returns no error when dropping
non-existent collections.
Branch: server-43894-followup
https://github.com/mongodb-js/mongosh/commit/35933f220013a2811aeb453acd50d095557a1fe5

Comment by Githook User [ 09/Feb/23 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}

Message: SERVER-43894 dropCollection should return success if the collection does not exist AND no UUID was specified
Branch: master
https://github.com/mongodb/mongo/commit/cbbd89e530107abb4fdf22cf02cf06665e52b53a

Comment by Daniel Gottlieb (Inactive) [ 25/Oct/19 ]

if the server was to not return this error at all this would potentially save work across all drivers.

I might be making a wrong assumption here. Suppose the spec mandates ignoring `ns not found` errors and the next mongodb version contains a patch for this ticket. I agree that drivers talking to the new version would never need to handle an `ns not found` error. But if a driver were talking to an older version of mongodb, wouldn't it be appropriate for the driver to explicitly ignore any `ns not found` error? If that's true, doing this ticket won't actually save any driver work. Or would that state be considered good enough? Where the API provided by the driver for drop collection changes based on which server version an application is connected to.

Comment by Oleg Pudeyev (Inactive) [ 10/Oct/19 ]

To my knowledge there is no specification covering dropping collections. There was a survey of drivers recently as to how they handle the nonexisting ns error with the following results:

Node - no special handling (error propagates to applications)
Swift - no handling, ticket open to suppress the error (https://jira.mongodb.org/browse/SWIFT-204)
Python - suppresses the error
C - no handling
Java - suppresses the error
PHP - suppresses the error
Ruby - sometimes suppresses the error

There is an open spec ticket (https://jira.mongodb.org/browse/SPEC-1053) to specify collection dropping behavior, specifically what to do about 'ns not found' error, in a consistent way across drivers.

As far as existing driver behavior is concerned, if the server stopped producing errors in the case of nonexistent collections, the drivers' behavior remains the same and backwards compatible, unless I am missing something.

Given that the spec ticket above proposes to mandate ignoring 'ns not found' errors, if the server was to not return this error at all this would potentially save work across all drivers.

Comment by Daniel Gottlieb (Inactive) [ 10/Oct/19 ]

oleg.pudeyev, I strongly agree with you that the server should treat dropping a non-existent collection a success. However, this behavior dates back for as long as I can remember and I'm worried that the downstream impact would result in more work than the alternative; simply having drivers cope with the response as it is today.

A change like this can only go into newer versions of MongoDB. I suspect drivers, in an effort to present a uniform API to clients, would still have to look for and transform drop "failures" because the collection does not exist into the successful variety. Otherwise, a driver may or may not report an error to the calling code with the only variable being the server version that it was talking with.

That being said, if there's buy-in among driver API stakeholders, we can do this. There are some subtle bugs we'd have to avoid (e.g: a WriteConcern: majority dropCollection cannot simply return) but it's certainly doable.

Would you like to raise this issue with the driver teams?

Generated at Thu Feb 08 05:04:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.