Successful durable function returns Result Code 500 if an exception is logged

[Ilia-Kosenkov]

Description

After enabling Distributed Tracing v2 and updating to latest versions of all packages, we noticed that failing activities and orchestrations now produce Response Code 500. However, we also observed that in select few cases, when an exception is thrown within an activity, but intercepted via try-catch and just simply logged, the activity Request has its Response Code set to 500 while Succeeded is set to True.

Expected behavior

If activity is successful, its Response Code should not be 500.

Actual behavior

Here is an example of such behavior:

Activity's request is marked as failed with 500, yet activity itself is fine, and its parent orchestration is also fine.

Request is marked as failed:

Yet Custom properties state that it was Succeeded: True

Since we use Storage account as backend in this particular service, I used Durable Functions Monitor for VsCode to double check if the activity is successful, and whether it brought down orchestration -- no, it completed successfully.

Now, for comparison, here is an actual activity that has failed via an uncaught exception, which in turn brought down its parent orchestration: activity, its invocation are now marked as failed, not only the request.

Known workarounds

Avoid logging exceptions?

App Details

• Durable Functions extension version (e.g. v1.8.3): Microsoft.Azure.Functions.Worker.Extensions.DurableTask v1.7.1
• Azure Functions runtime version (1.0 or 2.0): 2.0
• Programming language used: C#

If deployed to Azure

We are hosted on Azure but I cannot publicly share information. I can provide more details to a maintainer/Microsoft employee upon request, if needed.

[Mivaweb]

We have the same issue here when using resilience pipelines on the HttpClient used in activity functions.
When a request fails and we retry the request which then succeeds, it still results in a 500 response code but succeeded is true.