Unclaim a task / task cannot be claimed

Camunda 7 Topics Discussion & Questions
1

Hi,
I have these two issues:

  1. task cannot be claimed after it is assigned to “empty” user (variable has a value “”). The engine shows an error message saying “Task {taskId} is already claimed by someone else”
  2. if you call “claim” method to unclaim this task, the method is successfully called (engine shows success message) but nothing will happen.

Here is a sample process for tests and a “workaround” how to bypass this.
testEmptyAssignee.bpmn (16.4 KB)

image
image818×747 38.5 KB

Could somebody please take a look at this? The ideal solution would be someone from Camunda team :slight_smile: maybe @thorben? :slight_smile:

Thank you very much in advance :slight_smile:

2

Looks like you found a nice little bug (imo) in the engine.

But at the same time the flow of your actions are a little weird (imo)

  1. Why are you creating a empty string on the Start Event? Why do you have this placeholder at all if you are using the Create to do a claim? Also why is it a empty string vs using null. If you use null 1a is claimable. (tested)

  2. 1b: a loop is happening: Assignment listener is called when a task is assigned. Every time you are claiming the task (as a user), your assignment listener is executing and claiming to null: see docs for when the different listeners are called: Delegation Code | docs.camunda.org

  3. 1c works even with the fix for 1a.

  4. 2 works with fix above for 1a.

Generally is looks like the Tasklist UI and engine are treating "" as the same as null from a intial eval, but when you go to claim it thinks "" is a user.
Can see examples here:

nullassignee

task1a:
empotystringassignee

But the Tasklist UI will show a task that is assigned to "" as unassigned. Classic null vs empty string stuff/issues. @thorben this seems to be where the bug. The UI is showing the task is unassigned.

Any specific reason why you are using the Claim action? IMO using the claim action creates a redundant action/log for initial task creation: Aka: you are first generating a task that is assigned to null, and then you are claiming it. Something a little more clean from a tracking and reporting perspective would be to use Local variables:

In your Task 1a create an start execution listener that executes something like:

var assignee = execution.getVariable('a')
execution.setVariableLocal('myAssignee', assignee)

and set your Task 1a Assignee field to ${myAssignee}. You can keep reusing the same variables names for all of your user tasks because the scope of the ${myAssignee} will be local and only exist in the lifecycle of the specific task.
(you could also setup a Input Mapping to do the same thing if you like).

Again: doing the claim action seems to work, but pretty sure it would be generating additional logs/actions in the history db, so you would always have to remember which tasks are auto claimed if you are ever doing reporting on this sort of stuff.

1 Like
3

Hi Stephen,
thank you for your reply. The whole scenario (uploaded process) is not a real use case, it is just for simulation purpose only.
But I encounter this behavior more than a few times in the past and I decided to take a look at it now.

4

Hi guys,

Thanks for reporting. I created a bug issue: https://app.camunda.com/jira/browse/CAM-9118. I tried to reduce the problem to its core in the description. Please let us know if it misses an aspect.

Cheers,
Thorben

1 Like
5

Hi Thorben,
thank you, the issue is also affecting user who can not claim the task either. Workaround for user is reassigning the task in cockpit.
Cheers,
Lukas

6

@lhofer87 you could also do a test for tasklist behaviour vs API behaviour to see confirm where/if the tasklist API is showing “” as unassigned.

7

Hi Stephen,
you mean test for rest API (which is tasklist using) vs java API?