Exception is not propagated to parent orchestration as expected

[moldovangeorge]

Irrespective of the ErrorPropagationMode value that is set on the worker when running based on the SqlServerProvider, the Exception is not propagated up the stack as expected. My expectation was that the Exception that is caught in the parent orchestration would contain the exception that was thrown in the Activity either in the innerException field, or in the FailureDetails field. I ran a demo app using both UseFailureDetails and UseFailureDetails setup and in both cases the exception was not propagated correctly, and it only contained limited information in the message of the exception ( either the message of the inner exception, or the type of the inner exception, depending if the inner exception had a message or not).

Also, when using the UseFailureDetails setup, I expected to receive an OrchestrationException in parent orchestration but a TaskFailedException was raised instead.

[cgillum]

@moldovangeorge can you share the demo app that reproduces this issue?

[moldovangeorge]

Sure :

1. Clone the repo from here : https://github.com/MoldovanG/DaprWorkflowAnalysis
2. Replace YOUR_CONNECTION_STRING_HERE with a connection string to a SqlServer you have at hand
3. Modify the DtfActivity to throw exception instead of logging.
4. dotnet run
5. curl --location --request POST -k 'https://localhost:5004/api/dtfworkflow' --header 'Content-Type: application/json' --data-raw '{ \"numberOfParallelSubOrchestration\" : 1, \"numberOfParallelActivities\" : 1}'

[wros]

I have this same problem using the function, in isolated mode. The Exception is not propagated to the orchestration, and I cannot use the custom retry in the activity.

I'm using the Azure Version.

When I use the SQL Provider

Here when I don't use the SQL Provider:

Obs: I'm using the VS 2022 default template for Azure Functions.

[cgillum]

Thanks @wros for the additional context. This helps narrow things down. I haven't had a chance to look at this yet but hoping to get to it soon'ish.

[cgillum]

I spent some time debugging this and I think the problem is that the database schema needs to be updated to support correctly persisting detailed exception information. From what I can tell, we're only saving the exception message, which isn't something we can correctly deserialize back into code. This is definitely a missing feature.