Today, to handle errors on Kogito SW, users need to map a given Java Exception FQCN to the workflow error code. See: https://blog.kie.org/2021/11/error-handling-in-serverless-workflow.html

This is too tied to Java and is leaking our implementation. The error only can be caught by defining a Java Exception.

To make more context like, we can add an alternative that's caught HTTP status code instead.

Many interactions with remote services are done via HTTP. A remote service can return 404 for a request to a domain object that doesn't exist, for instance. In this case, users would leverage this interface with a remote invocation to design their workflows.

So an error handling definition could work like this:

        {
          "error": "our of stock",
          "code": "HTTP:404",
          "transition": "outOfStockHandling"
        }

For this implementation to work, every interaction with remote HTTP invocations must map this error logic. To this date, OpenAPI and the rest custom function. More analysis is required to extend this implementation if needed.