Missing `workflowExecutionResult` during error handling with Managed Workflow

[murillio4]

Bug Report

What did you do?

I attempted to handle errored dependents within managed workflow. I implemented ErrorStatusHandler in my reconciler and configured updateErrorStatus to update the CRD status with a list of failed dependents (including error messages) and successful dependents.

What did you expect to see?

The CRD status should display a list of failed dependents (with error messages) and successful dependents.

What did you see instead? Under which circumstances?

The CRD status was not updated because getWorkflowReconcileResult() returned null.

Environment

AKS kubernetes version: 1.30.4

$ Mention java-operator-sdk version from pom.xml file
4.9.4

$ java -version

openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

$ kubectl version

Client Version: v1.30.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.4

Possible Explenation

I seems both Controller.execute and DefaultWorkflow.reconcile are designed to handle workflow errors via throwAggregateExceptionIfErrorsPresent. The DefaultWorkflowhandles errors only if throwExceptionAutomatically is set to true, which it is by default (THROW_EXCEPTION_AUTOMATICALLY_DEFAULT is true).

However, the issue is that Controller.execute is responsible for setting the workflowExecutionResult. Since DefaultWorkflow.reconcile throws an exception when handling errors with throwAggregateExceptionIfErrorsPresent, the error handling in Controller.execute never hits, and workflowExecutionResult is never set.

[metacosm]

Indeed, there's an issue there. Thank you for the report. Can this wait for version 5 so that we can address this in a proper fashion as this would be rather complex to address this for version 4 of the SDK while maintaining backwards compatibility? The easiest solution would be to change the default value to not throw exceptions automatically but this would break the existing behavior.

[murillio4]

While I had hoped this would be addressed in version 4, I understand that fixing it now would break backward compatibility. Addressing it in version 5 makes sense.

Do you know when v5 is scheduled for release?

[murillio4]

I saw in your response to issue #2545 that you're waiting for the fabric8 client v7, which answers my question.

Do you expect this issue to be resolved in the initial v5 release, or will it come in a later patch?

[metacosm]

I will see if I can work something out for v4. It will definitely be in the first v5 release.

[murillio4]

Super! Maybe making throwExceptionAutomatically configurable through the ConfigurationService. Then default can be true making it backward compatible.

[metacosm]

See linked PR, let me know if this addresses the issue.

[murillio4]

Seems to work 🙂 workflowExecutionResult are now available in updateErrorStatus.