[Java API] Bug in `JobQuery` implementation in Management Service API?

Camunda 7 Topics Discussion & Questions
1

Continuing the discussion from Finding Job instance associated with a user task in a given process instance:

I found that when more than one process instances are running, Management Service API JobQuery can find all previous jobs except for the current process instance. That means,

  • for 3 process instances, timer jobs queried in the third process instance delegate are for the 2 previous process instancs,
  • for 2 process instances, timer job found is for 1 previous process instance and so on.
    When there is only one instance, there is no previous process instance and therefore, total job count is 0. Due to this, jobs for current querying process instance are always zero.

The REST-API shows all jobs for current process correct all the time. As of 29.01.2020, Camunda v7.13.0-SNAPSHOT, this bug only exists in Java API. This has been primarily tested with Timer jobs. Please read my detailed analysis on github as it’s too long to produce here.

I appeal Camunda developers to kindly take a look into it. I do not know procedure to open an issue on Camunda code base otherwise I would have directly done it there.

Thanks and Regards
Chaitanya Joshi

2

Hi,

This is not a bug but a limitation due to the nature how the process engine’s persistence works. When you make the query, the timer job has not yet been flushed or committed to the database, because that happens only when the current engine command finishes. So the job query will not be able to find the new job yet.

Cheers,
Thorben

edit: Check out Lookup Timer Due date for a Boundary event from Task Create Listener for a question and solution very similar to your case.

1 Like
3

Thanks a lot Thorben @thorben , this is definitely helpful and also probable solution to my question but then I have two follow up questions to this.

  • How can then REST-API find this job immediately? http://localhost:8080/engine-rest/job?processInstanceId=<instance-ID> finds the job for current process correctly.
  • Do you think there needs to be a mention of this limitation on documentation on either Job Executor or boundary events?

Thanks and Regards
Chaitanya

4

Hi Chaitanya,

The REST API works in a separate transaction and only sees committed data, so what you believe is immediate is only after the command that creates the job has finised. You could verify that by putting a breakpoint (or a long sleep) into the delegate. Then call the REST API while the delegate is blocked. The job shouldn’t appear.

Sure, I think this can be documented better. Transactions in Processes | docs.camunda.org would probably be the right place, because it does not only affect jobs and boundary events, but really any entity the process engine persists.

Cheers,
Thorben

2 Likes
5

Thanks a lot! This helped me a lot in knowing the internals of the engine better.

Regards
Chaitanya

6