Issue with DelegateTask.getCandidates()
Not Reflecting Deleted Candidate Groups in TaskListener (Camunda 7)
Hi everyone,
We’ve developed a plugin for Camunda 7 that hooks into various TaskListener
events. The listener is registered like this:
taskDefinition.addTaskListener(TaskListener.EVENTNAME_CREATE, globalTaskListener);
taskDefinition.addTaskListener(TaskListener.EVENTNAME_COMPLETE, globalTaskListener);
taskDefinition.addTaskListener(TaskListener.EVENTNAME_DELETE, globalTaskListener);
taskDefinition.addTaskListener(TaskListener.EVENTNAME_UPDATE, globalTaskListener);
Everything has been working smoothly. However, we recently started using identity links to manage candidate groups on UserTask
.
The Problem
In our implementation, GlobalTaskListener
implements TaskListener
. The issue arises when we delete a candidate group from a task:
- The
TaskListener
is correctly triggered onEVENTNAME_UPDATE
. - But when we call
delegateTask.getCandidates()
, it still returns the candidate group that was just deleted. - Interestingly, when adding a candidate group,
delegateTask.getCandidates()
reflects the change immediately.
What I’ve Tried
- I noticed that if I hook into the
HistoryEventHandler
, it properly captures theHistoryEventTypes.IDENTITY_LINK_DELETE
event. - However, my goal is to rely on the
TaskListener.EVENTNAME_UPDATE
trigger and have theDelegateTask
reflect the current, accurate state of identity links (i.e., candidate groups).
My Questions
- Why isn’t
delegateTask.getCandidates()
up-to-date after deleting a candidate group? - Is this behavior by design in Camunda 7?
- Could this be related to caching, or is it potentially a bug?
- Is there a recommended approach to ensure that, within the
TaskListener
, I get the correct, updated list of candidates after such changes?
I’ve searched through the documentation and forums but couldn’t find a clear explanation for this behavior.
Any insights, explanations, or workarounds would be greatly appreciated!
Thanks in advance!