Runtime exception handling using Spring Zeebe client

Camunda 8 Topics Discussion & Questions
1

Greetings,

I’m new to the Camunda Zeebe engine and currently using the Zeebe Spring client in my project. I’ve been exploring the proper approach for handling unexpected Runtime exceptions that may occur during service tasks(ex: NullPointerException) In specific cases, I explicitly throw a ZeebeBpmnError and have an error boundary event in place to catch these exceptions. However, for runtime exceptions other than ZeebeBpmnError, incidents occur, and the process breaks. Now I’m seeking an elegant solution to address these situations.

After reviewing the documentation, it seems that Camunda 8 does not have an incident handler API. Therefore, I have a few questions:

  1. Should incidents be resolved, and the process completed as if no incident had occurred?
  2. If so, is there a mechanism or handler that can be triggered during unexpected exceptions?
  3. Currently, I’m considering a custom approach using Spring AOP to wrap runtime exceptions and send an internal server error to Kafka, which would then publish a message to a WebSocket channel. However, in this case, the incident would remain unresolved, and I’m uncertain about the appropriate treatment of incidents in real-world scenarios. Is this approach a correct way of handling the situation, or should incidents be resolved programmatically, such as by canceling or completing the flow?

Any assistance would be greatly appreciated.

2

Hi @Coder92 , and welcome to the forum!

  1. this depends on the incident and the process. If it is a process without too strict compliance and if the NullPointer is e.g. due to a missing/wrong ProcessVariable and that can be updated afterwards, then it is absolutely possible to just update the ProcessVariable and increase the Retries, so the process can continue.
    2&3. The thing with unexpected exceptions is that they’re unexpected - so it’s not clear to me, how you would resolve them generically. If you would trigger some kind of handler and that handler would e.g. resolve the incident and increment the Retries, then the same exception would occur again and again? I’m gonna quote our docs here:
    “In Camunda Platform 8, an incident represents a problem in process execution. This means a process instance is stuck at a particular point, and requires user interaction to resolve the problem.”

So generally, I would say: If you can predict the e.g. Exception, you should be able to tackle it in a way no Incident occurs (by either preventing it from occurring or by gracefully processing it further, so no incident gets created).

I hope this answer is not too vague and that I captured the general topic of your question.

Incidents in the docs: Incidents | Camunda Platform 8 Docs
GET incidents via Operate API: Overview | Camunda Platform 8 Docs
React to Incidents via Zeebe API (e.g. via commands ResolveIncident, UpdateJobRetries, ModifyProcessInstance, CancelProcessInstance): Zeebe API (gRPC) | Camunda Platform 8 Docs

Hope this helps,
Jens

1 Like
3

Thank you for your reply and warm welcome!

In my second and third points, when I mentioned “unexpected exceptions,” I was referring to cases where the code doesn’t typically account for them because they are unpredictable. Examples of such exceptions include ClassCastException, UnsupportedOperationException, ConcurrentModificationException, and so on. Ideally, these exceptions should not occur, but real-world scenarios don’t always follow these ideal rules. In the context of a RESTful API, for instance, Spring offers a RestControllerAdvice that allows you to catch runtime exceptions and inform the user about an internal server error, thereby making them aware that something unexpected has happened on the server side. I’m currently unsure about the best approach to gracefully handle all unexpected runtime exceptions and their subclasses while sending an appropriate server error message to the user. Although using Spring AOP is one possible solution I’m considering, ideally, I would prefer to achieve this using the Spring Zeebe API. However, based on my exploration, it appears that no such API exists.

I would like to know if there is something that I may have overlooked in the documentation, or if Camunda 8/Zeebe does not offer a ready-made solution for this specific requirement, thereby requiring the application developer to implement custom error handling.