[SERVER-33276] Creation of already existing collection on a sharded cluster should be an error Created: 12/Feb/18 Updated: 27/Oct/23 Resolved: 12/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Jeffrey Yemin | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
For all cluster types (standalone, repl, sharded), attempting to create an already-existing collection should result in an error, as with this test against a 3.6 server:
But with a sharded cluster running on the nightly build it no longer does:
The behavioral difference was detected for the first time in this driver regression test. The git hash of the server in that test run is 3.7.1-280-g43fbd6a. The previous successful run of that test used a server with a git hash of 3.7.1-253-g2e1f172bc1. |
| Comments |
| Comment by Shane Harvey [ 05/Mar/20 ] | ||||||||||||||||||||||||||||||||||||||||||
I also would worry about bugs caused by this subtle BC break. A successful create command used to mean that the collection was created and empty. It could be surprising for users to discover that the collection might not be empty on sharded clusters.
Could mongos create the collection in a transaction to fix this issue (and regain NamespaceExists error consistency with replica sets)? | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 13/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Added the last comment as the description of | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 13/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Looks like there's more going on here than I thought. After disabling the first test, the next test suite caught another behavioral change. Here's a shell repro
The current behavior in 3.6 (and the behavior of replica sets on master), is that creating a capped collection without a size specified is an error:
| ||||||||||||||||||||||||||||||||||||||||||
| Comment by Randolph Tan [ 13/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||
|
jeff.yemin, once a request in mongos loses the connection to config server or shard, it is ambiguous whether the collection that exists after it re-establishes connection was created by it or someone else. In other words, it can happen both ways: if we preserve the old behavior, it can return "collection already exists" error even though the request created it originally. alyson.cabral What do you think about this? | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 12/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||
|
One more thought about this. I see that the second create will succeed even if the collection is not empty. This could cause issues for applications that may be expecting collection creation to fail for a non-empty collection. | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 12/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||
|
Feel free to close this then, and I'll disable the driver test that caught the change. | ||||||||||||||||||||||||||||||||||||||||||
| Comment by Randolph Tan [ 12/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||
|
This is by design to be able to allow mongos to retry create command when a primary steps down and not throw an error to the user if the create succeeded. It should error though if you try to create a new namespace with different options of what exists. |