[SERVER-60933] Make the sharded cluster's 'create' command behave the same as replica set Created: 22/Oct/21  Updated: 20/Feb/23  Resolved: 20/Feb/23

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Duplicate Votes: 0
Labels: shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-73553 Ensure mongos create command returns ... Open
Duplicate
duplicates SERVER-60064 Make create command idempotent on mongod Closed
is duplicated by SERVER-67828 Create collection on sharded cluster ... Closed
Related
Assigned Teams:
Sharding EMEA
Operating System: ALL
Sprint: Sharding EMEA 2021-11-29, Sharding EMEA 2021-12-13, Sharding EMEA 2021-12-27
Participants:
Linked BF Score: 11
Story Points: 3

 Description   

When a createCollection command is forwarded from the router to the database primary, it is possible to get a NamespaceExists error in case the collection already exists. When this happens, a listCollection command is issued in order to decide whether to return or not an error to the client (fail in case the collection exists with different options).

However, there is no guarantee that a collection does not get dropped before the call to listCollection. In case this happens, currently a "cannot find ns" error message is returned, that is very misleading considering that the command should create the namespace.



 Comments   
Comment by Tommaso Tocci [ 20/Feb/23 ]

This issue has been fixed in SERVER-60064 where we also made the create command idempotent on replset.

Comment by Githook User [ 06/Dec/22 ]

Author:

{'name': 'Dave Rolsky', 'email': 'autarch@urth.org', 'username': 'autarch'}

Message: REP-1717 Fix handling of NamespaceNotFound when creating temp collection name in older versions create event handler (#1032)

This addresses a BF in a stepdown ctc test. The mongosync instance crashed
with a fatal error because of an error from the create event handler. When the
create event handler tried to create the collection with a temp name it got a
`NamespaceNotFound` error. The server should not return this error, but there
is a server bug that causes it to do so,
(SERVER-60933(https://jira.mongodb.org/browse/SERVER-60933)). Then a bug
with our handling of these errors led to the crash.

This PR changes our `RunCommand` wrapper so that it always adds `writeConcern:
majority` and `j: true` to `create` commands. This will be done for more
commands later as part of REP-1733. This combined with the change in
[REP-1530](https://jira.mongodb.org/browse/REP-1530) that treats a
`WriteConcernError` as retryable. The end result is that we will simply retry
when we get this error during a stepdown rather than crashing.
Branch: main
https://github.com/10gen/mongosync/commit/1d891663f24a26232b07677058c507c72a402e1a

Comment by Frederic Vitzikam [ 05/Dec/22 ]

We got another related BF: https://jira.mongodb.org/browse/REP-1917 on a 4.2 sharded destination.

Comment by Kaloian Manassiev [ 03/Jan/22 ]

We should just throw out the whole handling of the NamespaceExists error and just forward the create command to the DB primary shard so that the behaviour is the same between standalone, replica sets and sharded cluster.

For whoever picks that up, here is an Evergreen patch with the failing tests: https://evergreen.mongodb.com/version/61d3252b0305b92df5f0ae8e

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