-
Type: Improvement
-
Resolution: Fixed
-
Priority: Trivial - P5
-
Affects Version/s: None
-
Component/s: None
-
2
When application passes invalid read concern sub-options to client, the client forwards those options ultimately to the server, and the server rejects the queries due to invalid read concern sub-options.
From the user experience standpoint, the application developer only finds out that the read concern sub-options were invalid after a query is issued. We could potentially improve developer experience by validating read concern sub-options during client construction, to provide earlier feedback about invalid sub-options.
A consideration here is forward compatibility with server versions that might add additional read concern sub-options or additional values to the existing sub-options like level.
This applies to:
1. Unknown options:
irb(main):008:0> a=Mongo::Client.new([],read_concern:{hai:9}) D, [2019-01-02T14:40:15.958429 #17296] DEBUG -- : MONGODB | EVENT: #<TopologyOpening topology=Unknown[]> D, [2019-01-02T14:40:15.958610 #17296] DEBUG -- : MONGODB | Topology type 'unknown' initializing. => #<Mongo::Client:0x47195355313360 cluster=#<Cluster topology=Unknown[] servers=[]>> irb(main):009:0> a.options[:read_concern] => {"hai"=>9}
In these cases I suggest warning that the option is unknown but keeping it and forwarding it to server and allowing the server to return an error.
2. Options which are not user-settable:
irb(main):008:0> a=Mongo::Client.new([],read_concern:{after_cluster_time:9, afterClusterTime:10})
I suggest raising an exception when these options are encountered.
Note that driver currently warns & discards on (other, not read concern) top level unknown options.