Uploaded image for project: 'Ruby Driver'
  1. Ruby Driver
  2. RUBY-1632

Handle bogus/invalid read concern sub-options

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Trivial - P5 Trivial - P5
    • 2.14.0.rc1
    • 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.

            Assignee:
            emily.giurleo@mongodb.com Emily Giurleo (Inactive)
            Reporter:
            oleg.pudeyev@mongodb.com Oleg Pudeyev (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: