Feature request: Add HandleResultAsync
See original GitHub issueHey everybody,
today I ran into a case where handling a result involved executing an async operation:
var policy = Policy<HttpResponseMessage>
.HandleResult(response => response.Content.ReadAsStringAsync().Result.Contains("pattern"))
.RetryAsync(retries, (exception, retryCount, context) => doSomething());
So as you can see, I need to access the content of the response to decide whether to retry or not. Unfortunately the only way to parse it is with async methods. So to get it to work with HandleResult
, I need to add Result
, which is not recommended and might lead to problems.
The obvious solution would be to add a HandleResultAsync
method to Polly, similar to e.g. Retry
and RetryAsync
. I haven’t looked at the code myself yet, but maybe it’s not too complicated to add the async counterpart and I think it would enable support for a quite frequent use case.
Anyways, I love using Polly. It makes things a lot easier, so thanks for that! 😃
Issue Analytics
- State:
- Created 6 years ago
- Reactions:4
- Comments:7 (5 by maintainers)
Top Results From Across the Web
Task.ContinueWith not very popular with async code?
To combine two asynchronous operations (e.g., InvokeSomeAsync and HandleResultAsync ), introduce an async method:
Read more >Cannot continue the execution because the session is in ...
I tried adding the non clustered first. I got this error. So I thought that I might have index corruption and tried to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
For anyone exploring this problem, this Stackoverflow answer explores a possible solution to a similar case.
With nested retry policies, wouldn’t it retry
retryCount ^ 2
times instead of justretryCount
times?