When re-creating a collection that was dropped via dropDatabase, if the create write concern is not honored the operation succeeds and no write concern error is returned.
AFFECTED DEPLOYMENTS
Only sharded clusters.
AFFECTED VERSIONS
At the time of writing this ticket: v8.0 and master.
REPRODUCIBLE
- db.runCommand({create:'a', writeConcern:{w:'majority', wtimeout:300}});
- db.dropDatabase();
- db.runCommand({create:'b', writeConcern:{w:'majority', wtimeout:300}}); // Implicitly re-create the db by creating another collection
- Block secondaries (e.g. stop replication on secondaries via fsync lock)
- db.runCommand({create:'a', writeConcern:{w:'majority', wtimeout:300}}); // This should fail with a write concern error but succeeds
- is caused by
-
SERVER-81189 Transform `create` requests in sharded cluster to `_shardSvrCreateCollection`
-
- Closed
-
- is related to
-
SERVER-98107 Investigate `create` write concern errors NOT propagated ONLY for collections that existed in the past
-
- In Progress
-