-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
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:
- Command Request Serialization --> Route to 5
- Command Request Deserialization
- Command Reply Serialization
- Command Reply Deserialization --> Route to 6
- Storage/Default Serialization (adheres to feature flag)
- 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).
- is depended on by
-
SERVER-70547 Create multitenancySupport passthroughs that inject a tenant prefix and security token
- Closed
-
SERVER-74284 Fix existing tests for command serialization/deserialization
- Closed
-
SERVER-74489 Make NamespaceString::toStringWithTenantId private
- Closed
-
SERVER-75930 Change command serialization/deserialization manual calls
- Closed
-
SERVER-76084 Create targeted tests for command de/serialization
- Closed