Skip to content

Injected latency should be cancellable #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
reisenberger opened this issue Jan 20, 2019 · 1 comment
Closed

Injected latency should be cancellable #20

reisenberger opened this issue Jan 20, 2019 · 1 comment
Assignees
Labels
community feedback wanted enhancement New feature or request help wanted Extra attention is needed
Milestone

Comments

@reisenberger
Copy link
Member

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.

@reisenberger reisenberger changed the title Should injected latency should be cancellable? Should injected latency be cancellable? Jan 20, 2019
@mebjas
Copy link
Member

mebjas commented Jan 24, 2019

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 reisenberger changed the title Should injected latency be cancellable? Injected latency should be cancellable Jun 30, 2019
@reisenberger reisenberger added the help wanted Extra attention is needed label Jun 30, 2019
@vany0114 vany0114 self-assigned this Jul 24, 2019
@vany0114 vany0114 added this to the V0.2 milestone Jul 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community feedback wanted enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants