-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
Repl 2020-08-24, Repl 2020-09-07, Repl 2020-09-21
There are two mongos commands in API Version 1 that forward their parameters to internal commands: "drop" forwards to "_configsvrDropCollection" and "dropDatabase" forwards to "_configsvrDropDatabase". Users should be permitted to call the mongos commands with apiVersion: "1", apiStrict: true, but if the internal commands aren't in Version 1 they'll reject these parameters.
In detail: a client call to "drop" (or "dropDatabase") on mongos with apiVersion: "1" and apiStrict: true follows these steps:
- mongos receives the "drop" request with apiVersion: "1" and apiStrict: true in cluster_drop_cmd.cpp
- mongos builds a "_configsvrDropCollection" command for the config primary
- mongos copies some fields from the "drop" request to the "_configsvrDropCollection" command with CommandHelpers::appendPassthroughFields. The API parameters are copied since they are not marked stripFromRequest in command_generic_argument.cpp
- The config primary receives "_configsvrDropCollection" with apiVersion: "1" and apiStrict: true
- The "_configsvrDropCollection" command rejects the request because it isn't in API Version 1.
In SERVER-49065 we fixed this by marking _configsvrDropCollection and _configsvrDropDatabase as part of API Version 1. But since _configsvrDropCollection/Database are internal commands they probably shouldn't be in API V1. Let's find a different way to support API version parameters in drop and dropDatabase on mongos.
- related to
-
SERVER-58794 _configsvrCreateDatabase and _flushDatabaseCacheUpdates should accept any API version parameters
- Closed
-
SERVER-58785 Unable to create a new collection on a sharded cluster when using versioned API with strict=True
- Closed