[SERVER-31488] dropping a drop-pending collection via applyOps is a no-op Created: 10/Oct/17  Updated: 30/Oct/23  Resolved: 18/Oct/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.6.0-rc1

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: rbfz
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-31478 Certain unrecoverable errors don't th... Closed
related to SERVER-31543 rollback uses non-system temporary na... Closed
is related to SERVER-29752 Two Phase Drops: support dropping of ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

load('jstests/libs/write_concern_util.js');
load('jstests/libs/uuid_util.js');
var rst = new ReplSetTest({nodes: 2});
rst.startSet();
rst.initiate();
 
var primary = rst.nodes[0];
var secondary = rst.nodes[1];
 
var db = primary.getDB('test');
var collName = 'foo';
 
stopReplicationOnSecondaries(rst);
 
function printCollections() {
    printjson(db.runCommand({listCollections: 1, includePendingDrops: 1}));
}
 
assert.writeOK(db[collName].insert({a:1}));
var uuid = getUUIDFromListCollections(db, collName);
 
jsTestLog("Drop");
printCollections();
assert.commandWorked(db.runCommand({drop: collName}));
printCollections();
var cursor = db.runCommand({find: uuid});
printjson(cursor);
assert.eq(1, cursor.cursor.firstBatch.length);
 
jsTestLog("Apply Ops with UUID on drop pending collection");
printCollections();
assert.commandWorked(primary.adminCommand({  "applyOps" : [ { "op" : "c", "ns" : "test.$cmd", "ui" : uuid, "o" : { "drop" : collName } } ] }));
printCollections();
cursor = db.runCommand({find: uuid});
printjson(cursor);
assert.eq(1, cursor.cursor.firstBatch.length);

Sprint: Repl 2017-10-23
Participants:

 Description   

If applyOps contains a drop operation on a drop pending collection's uuid, it currently drops the collection immediately. It should use the timestamp of the applyOps for two phase drop. This is required for rollback to complete successfully.



 Comments   
Comment by Githook User [ 18/Oct/17 ]

Author:

{'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}

Message: SERVER-31488 dropping a drop-pending collection via applyOps is a no-op
Branch: master
https://github.com/mongodb/mongo/commit/c8455a590399a1cd6f963ab84ec236188bc3672a

Comment by Spencer Brody (Inactive) [ 11/Oct/17 ]

If they're already drop-pending, I think the applyOps drop should probably just return OK and be a no-op, the collection is logically already dropped. Presumably it's already tracked by the DropPendingCollectionReaper from whatever got it into drop-pending state to begin with

Comment by Benety Goh [ 11/Oct/17 ]

applyOps allows dropping of system collections to support two phase drops for databases. See SERVER-29752.

Perhaps the right thing to do here is to explicitly disallow dropping of drop-pending collections (whether they are referred to by UUID or system.drop... name).

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