Replies: 3 comments
-
Looks like the SDK uses the default receive timeout set in the transport settings rather than the cancellation token when using the receiveAsync API. That seems like a bug to me as well, so I'll fix this |
Beta Was this translation helpful? Give feedback.
-
After further investigation, the real issue here appears to be that the AMQP library we use simply doesn't accept cancellation tokens. Instead, it only accepts TimeSpans as you can see here. I'll discuss this a bit more with my team. |
Beta Was this translation helpful? Give feedback.
-
Looks like there is already an ask out for adding support for cancellation tokens to the AMQP library in question here. Ideally they would add support and we could just pass along the cancellation token as expected. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Context
Description of the issue
DeviceClient.ReceiveAsync(CancellationToken cancellationToken) method does not exit when cancellationToken is cancelled.
The current tests simply verify that the task returns immediately when passed a cancellationToken that is already cancelled.
Code sample exhibiting the issue
Console log of the issue
Expected Result
Workaround
To workaround this I have changed my code to use the ReceiveAsync(TimeSpan) overload, but it feels hacky.
Beta Was this translation helpful? Give feedback.
All reactions