[SERVER-73108] Handle command request/reply serialization/deserialization Created: 19/Jan/23  Updated: 29/Oct/23  Resolved: 26/Apr/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Janna Golden Assignee: Hugh Tong (Inactive)
Resolution: Fixed Votes: 0
Labels: ntdi_must_have
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-70547 Create multitenancySupport passthroug... Closed
is depended on by SERVER-74284 Fix existing tests for command serial... Closed
is depended on by SERVER-74489 Make NamespaceString::toStringWithTen... Closed
is depended on by SERVER-75930 Change command serialization/deserial... Closed
is depended on by SERVER-76084 Create targeted tests for command de/... Closed
Assigned Teams:
Serverless
Backwards Compatibility: Fully Compatible
Sprint: Server Serverless 2023-03-06, Server Serverless 2023-03-20, Server Serverless 2023-04-17, Server Serverless 2023-05-01
Participants:
Story Points: 5

 Description   

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).



 Comments   
Comment by Githook User [ 24/Apr/23 ]

Author:

{'name': 'Hugh Tong', 'email': 'hugh.tong@mongodb.com', 'username': 'cortrain'}

Message: SERVER-73108 Handle command request/reply serialization/deserialization
Branch: master
https://github.com/mongodb/mongo/commit/2765240643c83cdc06711083e5c1bb8b4c4052f5

Generated at Thu Feb 08 06:23:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.