Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-73108

Handle command request/reply serialization/deserialization

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Serverless
    • Fully Compatible
    • Server Serverless 2023-03-06, Server Serverless 2023-03-20, Server Serverless 2023-04-17, Server Serverless 2023-05-01
    • 5

      The goal here is to honor serializer options being passed into the serializers and deserializers when being called by a command, which are only loosely coupled with the state of the feature flags.  There are 6 primary scenarios we need to consider:

      1. Command Request Serialization  --> Route to 5
      2. Command Request Deserialization
      3. Command Reply Serialization
      4. Command Reply Deserialization  --> Route to 6
      5. Storage/Default Serialization (adheres to feature flag)
      6. Storage/Default Deserialization (adheres to feature flag)

       

      Non-command scenarios 5 and 6 will maintain the existing behavior dictated by feature flag states.  As Scenario 1 maintains existing behavior since it is primarily used for server-to-server communication that is NOT dependent on Atlas Proxy, we should route it to Scenario 5.  Scenario 2 and 3 are described separately in the two sections here, and any names returned in command responses should adhere to those rules when deciding whether to prefix or not.  Scenario 4 is used primarily for deserializing requests from other servers (ie. complementary to Scenario 1), so it also abides by flag-defined behaviors (Scenario 6).

            Assignee:
            hugh.tong@mongodb.com Hugh Tong (Inactive)
            Reporter:
            janna.golden@mongodb.com Janna Golden
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: