[out-of-proc] `RetryContext.LastFailure` incorrectly captures thrown exception

[Ilia-Kosenkov]

Description

When inspecting RetryContext.LastFailure during activity retry cycle, I noticed that .ErrorType and .ErrorMessage are populated from Exception.Message, with .ErrorType being the first part of .Message, until a ':', while the remaining part of the .Message is copied to .ErrorMessage.

As a result of this, RetryContext.LastFailure.IsCausedBy<TException>() does not work, because it relies on .ErrorType, which is malformed.

If I drop ':' from my exception message, then .ErrorType is "(unknown)"

Expected behavior

• RetryContext.LastFailure.ErrorType is set to correct the exception type.
• RetryContext.LastFailure.ErrorMessage is set to .Message of the captured exception.
• RetryContext.LastFailure.IsCausedBy<TException>() works

Actual behavior

• RetryContext.LastFailure.ErrorType seems to be set to exception.Message sliced till first ':' or "(unknown)" if ':' is absent
• RetryContext.LastFailure.ErrorMessage seems to be set to exception.Message sliced from first ':' or the beginning of the message
• RetryContext.LastFailure.InnerFailure is null (cannot judge if this is useful or not)
• RetryContext.LastFailure.IsCausedBy<TException>() does not work

Relevant source code snippets

Had to scramble some info here. Here is the exception I throw from my activity:

And here is what I observe in the AsyncRetryHandler:

Known workarounds

I originally intended to append Reason: ... to exception messages as a workaround, but this lead me to discovery that ':' is treated specially (which made things even worse). I am considering (ab-)using this feature to simulate the intended behavior.

App Details

• Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.1.0
• Microsoft.Azure.Functions.Worker.Sdk 1.16.4
• Azure Functions v4
• .NET 8

[Ilia-Kosenkov]

I believe now it is a duplicate (or rather 'caused by') #2697. Please verify and close if it is so.

[davidmrdavid]

I agree the issues are related - we're looking to reconsider how we're treating inner exception handling in .NET isolated. Let me close this so we can use the issue you linked as the 'aggregate' ticket. Thanks

[cgillum]

Reactivating since this issue is broader than #2697. Specifically, 2697 only covers the correctness of IsCausedBy<T>() when we have the expected exception information available to us. This issue covers the case where the Durable extension receives unexpected exception information.