In our application, we have a listener to a TIMER_FIRED event. When it refers to a non-canceling boundary timer event on a user task, we would need the task instance ID the event refers to.
In a trivial case with a single task instance of a particular type, this can be achieved by the means of the following query: getProcessEngine().getHistoryService().createHistoricTaskInstanceQuery().unfinished().processInstanceId(processInstanceId).taskDefinitionKey(boundaryEvent.getAttachedToRefId()).singleResult().getId()
This approach becomes inapplicable though, as soon as there exist multiple task instances of the same type (created, for instance, in a loop).
Do you see a more reliable way to find the task instance of interest in this case?
The TIMER_FIRED has an entity in the event. The entity in this case is the job entity, which has an executionId. Using that executionId, you can retrieve the related task (it has an executionId).
I tested this and it seems that the execution ID of the event is not the same as the execution ID of the task. However, the parent execution of the job entity had the same ID as the execution of the task.
Could you confirm that this will always be the case?
Also, could it fail due to concurrency when the task gets completed at the same time as the event handler is still firing? Or is that not be possible due to locking?