Issue with Task Execution in Camunda 8.5

Hello,

I’m encountering a problem with the execution of one of my business processes in Zeebe Camunda 8.5.0. During execution, a task that is supposed to compute a delay for a timer expires immediately. When inspecting the variables in Camunda Operate, I notice that the timer value is set to “now,” which explains why the timer expires instantly.

image

However, based on the current implementation, the delay value should be set in the future, not to “now.” In addition, I can’t find any log traces of this job worker being executed, while I do see logs for other tasks that run before and after it.

I tried renaming the main business process, but that didn’t resolve the issue. Interestingly, when I rename the problematic job workers, I do see logs in Kibana indicating that the job worker is executed correctly and the calculated date is as expected.

Renaming job workers every time a problem occurs is not a viable solution for me.

Could you help me understand why this task appears to be executed successfully from Camunda Operate’s perspective, but I don’t see any corresponding logs in my environment? I only have a single Kubernetes cluster, and all logs are routed to Kibana, so I would expect to see logs for this task as well.

Thank you in advance for your help!

Can you show how you’re creating the variable?

Here is the job worker responsible to compute the timer expiry date.

    @JobWorker
    @SuppressWarnings("unused")
    public Map<String, ZonedDateTime> computeDelay(@VariablesAsType DelayVariables variables, final ActivatedJob job) {

        LocalDate startDate = variables.getStartDate() == null
                ? LocalDate.now(ProcessService.DEFAULT_ZONE_ID)
                : variables.getStartDate().withZoneSameInstant(ProcessService.DEFAULT_ZONE_ID).toLocalDate().plusDays(1L);

        ZonedDateTime expiryDate = startDate.plusDays(10L).atStartOfDay(ProcessService.DEFAULT_ZONE_ID);
        
        return Collections.singletonMap(ProcessConstants.KEYS.TIMER_EXPIRY_DATE_KEY.value, expiryDate);
    }

And here is the variables object.

@Builder
@Getter
@Setter
@RequiredArgsConstructor
@AllArgsConstructor
public class DelayVariables {

    private String timerName;
    private ZonedDateTime startDate;

}

Configuration of the task

I have done some testing :

  • I cleaned the data folder of zeebe
  • I cleaned the elasticsearch indexes (for Operate)
  • I deployed a minimalist BPMN with just 2 tasks

The task named “computeDelay” is executed by Zeebe but without any calls to my backend.

I also deployed a backend with no @JobWorkers but the computeDelay task is still executed. The next task remains waiting for a jobWorker.

I am very lost with the zeebe behavior and it scares me for the day I will have to go live.

My final test before scratching the entire PVC is to change the credentials to make sure that nothing else can connect to zeebe.

PS: If I rename computeDelay to computeDelay2, everything is fine.

Hi, it might be out of topic, but first, I would start by cleaning up your worker code:

  1. Remove Lombok, as it can unexpectedly interfere with other components, such as having an influence on serialization, etc.
  2. Use a very standard way to create a worker, like this example (with implementing JobHandler (I know, when using @JobWorker you do not need it, but it is useful in other scenarios, e.g., where you have to create a utility function that accepts all workers as parameters), and ensure you read and write variables appropriately using autoComplete = false."
@Component
@SuppressWarnings("unused")
public class PersistOneEntityStandardWorker implements JobHandler {

    private static final Logger logger = LoggerFactory.getLogger(PersistOneEntityStandardWorker.class);

    private final OrchestratorOneService oOneService;

    public PersistOneEntityStandardWorker(OrchestratorOneService oOneService) {
        this.oOneService = oOneService;
    }

    @JobWorker(type = "persistOneEntityStandardWorker", autoComplete = false)
    public void handle(final JobClient client, final ActivatedJob job) {

        ProcessInstanceVariables variables = job.getVariablesAsType(ProcessInstanceVariables.class);

        OneEntity oneEntity = new OneEntity(variables.getBusinessCorrelationId().toString(), "body one standard");
        OneEntity oneEntityPersisted = oOneService.createOneEntity(oneEntity).block();

        variables.setOneEntity(oneEntityPersisted);

        client.newCompleteCommand(job.getKey())
                .variables(variables)
                .send() // .join() would block
                .exceptionally(throwable -> {
                    throw new RuntimeException("Could not complete job " + job, throwable);
                });

        logger.debug("PersistOneEntity standard way system task {} completed!", job.getKey());
    }
}

Maybe this will help to find the reason of the “strange” behavior.

Hi,

Thank for your reply, I will give it a try.

Side note :

  • The code is working locally on my working station (docker)
  • The code is working on my DEV environment (similar to TEST with K8S)

It’s realy one env that seems “corrupted”.

Ok, than “cleaning up the code” will not help, but might be a good upgrade for the future tries :slight_smile:

I changed the Zeebe client secret.

After that, the computeDelay job was no longer executed — not even by my local backend. It was as if Zeebe couldn’t find any eligible JobWorker.

After cleaning /data and /tmp on Zeebe, it started working again…

All of this remains very mysterious.
(And of course, I can’t do that in a production environment.)

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.