|
Closing this as won't fix. The way that an unstable field with a default value could manifest as an API Strict error is if the mongos parses the request (thus adding the default parameter) and then turns the parsed request back to BSON to forward to the mongods (who will then fail to parse because the unstable parameter is included with apiStrict=true).
The reason for closing is that there are many places in the code that rely on a default value existing for an unstable parameter, but their command implementation will not run into the issue above (because mongos will not forward the parsed request, but the original request). Requiring them to not have a default value will force us to change the code to support optional parameters. The intent for many of these parameters is to eventually make them stable, in which case when we make the parameter stable, we'd switch back to using a default and have to change the code back to the way it was. This is unnecessary work for commands that don't even run into the original issue. Since a test exists to find these errors, patch builds will fail if there is a new instance of a default value for an unstable parameter that could cause an API Strict Error.
|