In isolated mode, RetryContext.LastFailure.IsCausedBy is not useful if activity function is async

[buckprime]

It seems like we need more information about the last error in retry handlers (meaning RetryHandler/AsyncRetryHandler, that you can put into a TaskOptions to specify custom handling of retries). The retry handler gets called with a RetryContext, which has a call LastFailure.IsCausedBy() that is supposed to let you check what exception caused the failure you're retrying. But if the activity function that failed was async, the exception that the RetryContext sees is always AggregateException rather than the actual exception that was thrown. The context only contains the name of the type of the exception, so there's no way to determine what the actual exception was.

I think that the context either needs to know what the original exception was, or provide more information about the exception so that, for instance, if it's an AggregateException we can tell what exceptions it contained. Otherwise IsCausedBy isn't useful if your activity function is async.

[cgillum]

It would be good to better understand why AggregateException is being seen, since that's often not a very useful exception generally. But another thought I have is that IsCausedBy could be made smarter to look into inner exceptions to see whether the specified exception is included in the chain.

[thomaseyde]

...IsCausedBy could be made smarter to look into inner exceptions ...

That would probably be the easier fix. Right now, the only option is to inspect the error message which is less than ideal.

Current design is broken. There is nothing I can do to not throw an AggregateException.

[cgillum]

Are you not using await in your code? What API calls are throwing AggregateException? I'm not sure how to reproduce this.

[thomaseyde]

Are you not using await in your code?

Mostly, yes. Some methods are passthrough, which may return the task without awaiting it. Sometimes I fanout by adding tasks to a list, then await Task.WhenAll().

All tasks will be awaited in activities and orchestrations. Still, the AggregateException is what is thrown and logged. While I can walk the extra mile and await all tasks in my code, I have no control over 3rd party code like NuGet packages.

But why does it matter? There are several reports about AggregateException being thrown. I can imagine designs where RequestFailedException is thrown, and exception which is useless, unless you have access to ErrorCode.

The most powerful design would let us inspect the exception thrown. Then the developer is able to make informed decisions on how to retry. You can also drop the convoluted lookup code in IsCausedBy.