Incident was not created even same service task failing multiple times


I am using zeebe broker and spring-zeebe-starter as a client. if the same service task fails I am throwing an exception then the log says sending a fail command to broker. Still, broker not creating the incident. so it repetitively calling the same service.

here is my code and logs

	@ZeebeWorker(type = "saveUser")
	public void saveUser(final JobClient client, final ActivatedJob job) {
                     	Com com = getCom(job);  
                       throw new WorkflowException("excpetion  some error");

client.newCompleteCommand(job.getKey()).payload(toJson(com )).send().join();


here is my log from spring boot client

2019-05-15 16:25:48.809e[0;39m e[33m WARN [sample-component-workflow-handler,,,]e[0;39m e[35m17976e[0;39m e[2m---e[0;39m e[2m[pool-8-thread-1]e[0;39m e[36mio.zeebe.client.job.worker              e[0;39m e[2m:e[0;39m Worker component-workflow-handler failed to handle job with key 100242 of type saveUser, sending fail command to broker

java.lang.reflect.InvocationTargetException: null
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.base/java.lang.reflect.Method.invoke(
	at io.zeebe.spring.client.bean.MethodInfo.invoke(
	at io.zeebe.spring.client.config.processor.ZeebeWorkerPostProcessor.lambda$null$1(
	at io.zeebe.client.impl.subscription.JobRunnableFactory.executeJob(
	at io.zeebe.client.impl.subscription.JobRunnableFactory.lambda$create$0(
	at java.base/java.util.concurrent.Executors$
	at java.base/
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.base/java.util.concurrent.ThreadPoolExecutor$
	at java.base/
Caused by: com.sample.model.workflow.WorkflowException: excpetion  some error
	at org.springframework.cglib.proxy.MethodProxy.invoke(
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(
	... 14 common frames omitted


Hi @regojoyson,

  1. How many retries specified in your BPM model for this task?
  2. What version of the broker are you using?
  3. Can you share your sample code and BPMN model in a GitHub repo?



Hi, @jwulf Thanks for the quick response.

I am using following versions
zeebe broker : camunda/zeebe:0.17.0 (docker)
spring client : spring-zeebe-starter:0.4.0

Number of retries : 3

the incident was not creating only in spring-zeebe-starter. but if I use zeebe-client-java it works fine.

I will share my code tomorrow.



Which is the best client to use with spring boot? spring-zeebe-starter or zeebe-client-java

Any suggestions Please.


Hi @regojoyson - spring-zeebe-starter is not as well maintained as the zeebe-client-java:


When you are selecting an open-source component to base your project on, you want to use something that has traction and is being actively maintained.

Here is what I suggest:

Given that you have isolated the issue to the Spring starter, create a minimal reproducer repo (see: and push it to GitHub. Then open an issue in the Zeebe Spring Starter repo, and link to your reproducer.

Then see how fast it gets addressed. If there are no engineering resources being applied to zeebe-spring-starter (from Camunda or the community) then go with the one that has momentum for your project.

The benefit of open source is that you leverage the momentum of a community.


Hi @regojoyson,

thanks for reporting this issue. I was able to reproduce it and created the following issue

I also created a PR to fix the underlying problem



Looks like that project has some traction :grinning: