Respect timeout when cancellation token is provided

[JakubKopys]

Context

Our code runs the MQTT Client in a Background Service.

Problem

Providing any CancellationToken to any of those methods - ConnectAsync, PingAsync, DisconnectAsync, SubscribeAsync, and UnsubscribeAsync disregards the Timeout option.

In Background Services, we always provide the cancellation token, so if we are not aware of this behaviour, those methods will never timeout, disregarding the WithTimeout or Timeout completely. I do acknowledge this is partially mentioned in the Sample for timeouts, though, and it is recommended to use a linked token source.

I found it confusing, so I'm suggesting a change.

Solution

Instead of disregarding the Timeout, those operations should always consider it and link the cancellation sources.

I'm also aware this is a breaking change, as it'd cause Timeouts for existing code that depends on overwriting this with a linked token with an expiry.

Thank you for considering this contribution. I appreciate any feedback or suggestions for change. Alternatively, we could consider improving the sample and/or documentation.

[JakubKopys]

@dotnet-policy-service agree

[chkr1011]

I understand the issue and the change look reasonable to me. The HTTP client in .NET behaves in the same way. The shorter timeout (or cancellation token) will cancel the operation. The only thing which I am thinking about is the breaking change you already mentioned.

When I am not wrong the breaking change will only affect users which cancel the passed cancellation token LATER than 100 seconds (default timeout in options, or custom value). Then the timeout will happen earlier as expected.