You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, latency injected by MonkeyPolicy.InjectLatency(...) or MonkeyPolicy.InjectLatencyAsync(...) is not cancellable, in either the sync (1; 2) or async (1; 2) implementations.
Async case
Not allowing cancellation doesn't seem right in the async case. Async APIs of typical systems called through Polly typically support cancellation. By providing a MonkeyPolicy.InjectLatencyAsync(...) that doesn't support cancellation, we don't allow users to test how their production system would respond if there was (say) an extra 20ms latency.
For example, if the call is to some Azure SDK API which accepts a CancellationToken and the user is using an TimeoutPolicyAsync() or their own timing-out CancellationToken, then the call would typically cancel when the token is signalled. To allow users to simulate (in prod; or unit tests) that that behaviour works, the injected latency would want to be cancellable too.
Recommend: Change MonkeyPolicy.InjectLatencyAsync(...) to honour the CancellationToken passed to the .ExecuteAsync(...) call through the policies.
Option (now or later): Add an bool isCancellable parameter to (some) overloads of MonkeyPolicy.InjectLatencyAsync(...), allowing the user choice over whether they are injecting cancellable or non-cancellable latency.
Sync case
The sync case seems opposite. Sync APIs typically don't support cancellation. Therefore, it would be a more realistic simulation for the sync MonkeyPolicy.InjectLatency(...) to not support cancellation, at least by default.
Recommend: Leave MonkeyPolicy.InjectLatency(...) not honouring the CancellationToken passed to the .Execute(...) call through the policies.
Option (now or later): Add an bool isCancellable parameter to (some) overloads of MonkeyPolicy.InjectLatency(...), allowing the user choice over whether they are injecting cancellable or non-cancellable latency.
The text was updated successfully, but these errors were encountered:
Makes sense, the Async implementation should have cancellation support. I could have the injection deep in the call stack while cancellation could be signaled from much top layer.
reisenberger
changed the title
Should injected latency be cancellable?
Injected latency should be cancellable
Jun 30, 2019
Currently, latency injected by
MonkeyPolicy.InjectLatency(...)
orMonkeyPolicy.InjectLatencyAsync(...)
is not cancellable, in either the sync (1; 2) or async (1; 2) implementations.Async case
Not allowing cancellation doesn't seem right in the async case. Async APIs of typical systems called through Polly typically support cancellation. By providing a
MonkeyPolicy.InjectLatencyAsync(...)
that doesn't support cancellation, we don't allow users to test how their production system would respond if there was (say) an extra 20ms latency.For example, if the call is to some Azure SDK API which accepts a
CancellationToken
and the user is using anTimeoutPolicyAsync()
or their own timing-outCancellationToken
, then the call would typically cancel when the token is signalled. To allow users to simulate (in prod; or unit tests) that that behaviour works, the injected latency would want to be cancellable too.Recommend: Change
MonkeyPolicy.InjectLatencyAsync(...)
to honour the CancellationToken passed to the.ExecuteAsync(...)
call through the policies.Option (now or later): Add an
bool isCancellable
parameter to (some) overloads ofMonkeyPolicy.InjectLatencyAsync(...)
, allowing the user choice over whether they are injecting cancellable or non-cancellable latency.Sync case
The sync case seems opposite. Sync APIs typically don't support cancellation. Therefore, it would be a more realistic simulation for the sync
MonkeyPolicy.InjectLatency(...)
to not support cancellation, at least by default.Recommend: Leave
MonkeyPolicy.InjectLatency(...)
not honouring the CancellationToken passed to the.Execute(...)
call through the policies.Option (now or later): Add an
bool isCancellable
parameter to (some) overloads ofMonkeyPolicy.InjectLatency(...)
, allowing the user choice over whether they are injecting cancellable or non-cancellable latency.The text was updated successfully, but these errors were encountered: