Summary

 
When starting the swf-dev-mode image with a workflow definition that contains a compilation error (e.g., a non-existent start node), the initial deployment fails as expected. However, after fixing the workflow and triggering a Quarkus live reload (e.g., by accessing Swagger UI), the application becomes unrecoverable due to a java.lang.IncompatibleClassChangeError. The only recovery path is a full restart of the application after killing the pod/container with the new fixed workflow.

This issue prevents normal iterative development when starting with a broken workflow.

Environment

• swf-dev-mode image

• Quarkus (using dev profile)

• Kogito Addons: quarkus.knative.serving.customfunctions

• Live reload triggered via Swagger UI or HTTP call

Steps to reproduce

1. We have a workflow that we know that the compilation will fail. e,g. use as start node 

   start: NeverExistingNode

   Compilation of such a WF will fail, since we don't have node with that name as part of the WF definition, etc.
    

2. We start swf-dev-mode image locally, by using this workflow, or we can also deploy that workflow using the dev profile. (in both cases we have the same result)
    
3. ok, the initial deployment will fail
    
4. if we fix the WF and refresh the app, e.g. using the link to the swagger-ui to make the Quarkus live reload activate, we get the attached exception, and it's not possible to recover the build.

Actual results

• Live reload fails with the following exception:

  Caused by: java.lang.IncompatibleClassChangeError: class org.kie.kogito.addons.quarkus.knative.serving.customfunctions.KnativeWorkItemHandlerConfig_ClientProxy cannot inherit from final class org.kie.kogito.addons.quarkus.knative.serving.customfunctions.KnativeWorkItemHandlerConfig
      at org.kie.kogito.addons.quarkus.knative.serving.customfunctions.KnativeWorkItemHandlerConfig_Bean.proxy(Unknown Source)
      at org.kie.kogito.addons.quarkus.knative.serving.customfunctions.KnativeWorkItemHandlerConfig_Bean.get(Unknown Source)
      at org.kie.kogito.addons.quarkus.knative.serving.customfunctions.KnativeWorkItemHandlerConfig_Bean.get(Unknown Source)
      at io.quarkus.arc.impl.InstanceImpl.getBeanInstance(InstanceImpl.java:325)
      at io.quarkus.arc.impl.InstanceImpl$InstanceIterator.next(InstanceImpl.java:363)
      at org.kie.kogito.process.impl.AbstractProcessConfig.mergeWorkItemHandler(AbstractProcessConfig.java:88)
      at org.kie.kogito.process.impl.AbstractProcessConfig.<init>(AbstractProcessConfig.java:71)
      at org.kie.kogito.app.ProcessConfig.<init>(ProcessConfig.java:38)
      at org.kie.kogito.app.ProcessConfig_Bean.doCreate(Unknown Source)
      at org.kie.kogito.app.ProcessConfig_Bean.create(Unknown Source)
      at org.kie.kogito.app.ProcessConfig_Bean.create(Unknown Source)
      at io.quarkus.arc.impl.AbstractSharedContext.createInstanceHandle(AbstractSharedContext.java:119)
      at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:38)
      at io.quarkus.arc.impl.AbstractSharedContext$1.get(AbstractSharedContext.java:35)

• Application remains in a broken state and cannot be recovered through additional workflow changes or reloads.
   
• Requires full restart to return to a functional state.

Expected results

• After fixing the workflow and triggering a reload, the application should recover and correctly redeploy the updated workflow
   
• Live reload should function as expected for valid workflow definitions, even if the initial one failed.

Workaround

I
This issue only manifests when the initial deployment is broken. If the initial workflow is valid, you can introduce compile-time errors, and then see the error on live reload, fix the errors, and finally recover successfully via live reload, because the initial deployment succeeded.

So, basically, the workaround is to reploy again with a fixed workflow:

1. Fix the issues
2. [Openshift] Delete the deployment/ [Local]Shut down the devmode container
3. [Openshift] Apply the workflow again with the fixed workflow/ [Local] Start the container again with the fixed workflow

Testing

• Reproduced consistently when starting with a broken workflow.
   
• Live reload fails only when fixing from a broken initial state.
   
• Starting from a valid workflow does not trigger the error.