Callback registered with SetDesiredPropertyUpdateCallbackAsync not called unless desired properties set while active connection
Closed this issue · 7 comments
If you use RegistryManager to set a desired property on a twin, create a DeviceClient (AMQP or MQTT), register a callback with DeviceClient SetDesiredPropertyUpdateCallbackAsync, and OpenAsync() the client your handler registered does not get called. However, if you set the desired property after OpenAsync, the callback is called. This would then seem to necessitate that every time a client connects it needs to make a second call to GetTwinAsync to get any pre-existing desired changes.
General flow:
await registryManager.UpdateTwinAsync(twin.DeviceId, twin, twin.ETag);
await deviceClient.SetDesiredPropertyUpdateCallbackAsync(OnDevicePropertyUpdateRequestedAsync, deviceClient);
await deviceClient.OpenAsync();
Packages:
<package id="DotNetty.Buffers" version="0.4.7" targetFramework="net461" /> <package id="DotNetty.Codecs" version="0.4.7" targetFramework="net461" /> <package id="DotNetty.Codecs.Mqtt" version="0.4.7" targetFramework="net461" /> <package id="DotNetty.Common" version="0.4.7" targetFramework="net461" /> <package id="DotNetty.Handlers" version="0.4.7" targetFramework="net461" /> <package id="DotNetty.Transport" version="0.4.7" targetFramework="net461" /> <package id="Microsoft.AspNet.WebApi.Client" version="5.2.4" targetFramework="net461" /> <package id="Microsoft.Azure.Amqp" version="2.2.0" targetFramework="net461" /> <package id="Microsoft.Azure.Devices" version="1.6.0" targetFramework="net461" /> <package id="Microsoft.Azure.Devices.Client" version="1.7.1" targetFramework="net461" /> <package id="Microsoft.Azure.Devices.Shared" version="1.5.0" targetFramework="net461" />
Is there a response to this open issue - experiencing the same scenario and is not ideal to have to implement multiple ways to ensure desired property updates are managed depending on connectivity state... This issue was labeled as investigation-required over a year ago. Has this scenario been looked at?
Sorry about the delay in addressing this. Could you please provide details such as below for us to start investigation.
OS, version, SKU and CPU architecture used:
Application's .NET Target Framework :
Device:
SDK version used:
As I have not received more details on this issue I'm closing it for now. Feel free to reopen this issue if you have further information.
@v-tbert, @msivers, @prmathur-microsoft, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey
I'm working on a DeviceClient again and I hit this issue again. It seems like a intentional design decision that I think should be changed. It appears that existing desired properties don't get sent to the deviceclient when it first connects. In my opinion, an overload of SetDesiredPropertyUpdateCallbackAsync should be added that specifies that you want to receive any existing desired properties upon connection. That would be more efficient than the client always getting the device twin when it connects just to see if it has desired properties.
How can I re-open this as a feature request?