Closed uriel-kluk closed 4 months ago
Do you see this same behavior when using AMQP as well?
Hi Tim,
I just tested with:
var options = new ClientOptions { ModelId = _modelId, }; var client = DeviceClient.Create(result?.AssignedHub, authentication, TransportType.Amqp, options);
And got the same results as before. The callback did not trigger.
From: Tim Taylor @.> Sent: Wednesday, January 17, 2024 12:50 PM To: Azure/azure-iot-sdk-csharp @.> Cc: Uriel Kluk @.>; Author @.> Subject: Re: [Azure/azure-iot-sdk-csharp] Desired Properties callback not triggering after a reconnect (Issue #3423)
Do you see this same behavior when using AMQP as well?
— Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-iot-sdk-csharp/issues/3423#issuecomment-1896439821, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJ2NCA3LM64FPA6DW5UCAALYPAMPZAVCNFSM6AAAAABBYMICFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJWGQZTSOBSGE. You are receiving this because you authored the thread.
@timtay-microsoft , the documentation now says that you have to explicitly pull the device twin document. We have devices in the field that used to get the callback triggered and now these don't.
This is the comment in the code that we previously deployed: // After a reconnection to the IoT Hub, // It's not strictly necessary to explicitly retrieve the device twin // because the IoT Hub will automatically push any desired property 'updates' // that occurred while the device was disconnected.
Could you help me track down if there indeed is a change on IoT Hub?
I believe the SDK team has always recommended that you do a getTwin call upon reconnection to "catch up" on any twin changes that happened while a device was disconnected.
However, if you are seeing a change in behavior from the IoT hub side, then I'd recommend opening a support ticket through the Azure Portal for your IoT hub in particular. The service team has been slowly making a major upgrade to Hubs and it is possible that your Hub was upgraded and came with this is regression. The support ticket should connect you to a service-side engineer who can look at your hub in particular to see if this is the case.
Closing this issue as I believe this is a question of service behavior, not SDK behavior.
I believe this used to work, surely I tested it many times with IOTC. but I started a new project connected to IoT Hub and got the same behavior as #450.
The following registration triggers as expected a callback when the device is connected:
await _client.SetDesiredPropertyUpdateCallbackAsync(OnDesiredPropertyChanged, _client, cancellationToken);
But if the device is disconnected and I change the device twin, it won't trigger.
The same thing happens with IoTEdge, therefore, it might be a problem with IoT Hub device twin not pushing the changes on reconnection.
Here is the client setup code:
More details:
The twin shows the following elements: