Fix twin desired property payload conversion - MQTT #3322
Conversation
tmahmood-microsoft
requested review from
drwill-ms,
timtay-microsoft,
abhipsaMisra,
andyk-ms,
brycewang-microsoft and
patilsnr
as code owners
| @@ -1158,7 +1158,7 @@ private void HandleReceivedDesiredPropertiesUpdateRequest(MqttApplicationMessage | |||
| // This message is always QoS 0, so no ack will be sent. | |||
| receivedEventArgs.AutoAcknowledge = true; | |||
|
|
|||
| Dictionary<string, object> desiredPropertyPatchDictionary = _payloadConvention.GetObject<Dictionary<string, object>>(receivedEventArgs.ApplicationMessage.Payload); | |||
There was a problem hiding this comment.
Was _payloadConvention null here or something? Why do we want to always use the default payload convention?
There was a problem hiding this comment.
Since the payload from service client is always converted using default Payload/Newtonsoft.Json
There was a problem hiding this comment.
Sounds good then. Leave a comment to that effect here for future reference.
There was a problem hiding this comment.
+1 to adding a comment in here explaining why default convention is used. You could reference the fact that we deserialize this into a dictionary based on service defined convention of it being a utf-8 encoded json string.
There was a problem hiding this comment.
Since the payload from service client is always converted using default Payload/Newtonsoft.Json
Not quite. However it was sent from the service client, it is just JSON.
The problem is that our SDK deserializes the twin using Newtonsoft.Json. Then, individual properties can be deserialized to the user's choice, but not until after we've converted them back to bytes using the default payload convention again.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
tmahmood-microsoft
deleted the
tmahmood/mqtt-desired-properties-conversionFix
branch
No description provided.