Bug in the camunda tests?

Hi at all,
I think I found a bug in the camunda engine/test and I want to know if I am right:
Some context: I have a 2 Task process. In the first task I am entering some data, for example the variable EXAMPLE_DATE, in wich I want to store a date. You dont have to enter this date, its optional. In the second task I want to set the Due Date of the second task to EXAMPLE_DATE automatically.

So if I write in my Due Date of the second task:
${empty EXAMPLE_DATE? null: EXAMPLE_DATE}
My tasklist is working fine. If EXAMPLE_DATE is empty or not, it does not matter.
But when I am trying to test this, I am getting following error:

org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: ${empty EXAMPLE_DATE? null: EXAMPLE_DATE}. Cause: Cannot resolve identifier 'EXAMPLE_DATE'

Then I tried to write following line in my Due Date:
${execution.getVariable('EXAMPLE_DATE')}
When I am using this line, my test is working fine. However in my tasklist the task is just not created. The engine throws following message:

org.camunda.bpm.engine.ProcessEngineException: ENGINE-09027 Exception while resolving duedate ‘’: Invalid format: “”

Do you have any ideas on this? Is this a bug or am I missing something?

Hi @MarvinKern I think the difference is in the fact that the execution.getVariable call will just return null, but apparently the ternary evaluation will trip on that. Not sure whether that is supposed to happen; the documentation seems to indicate you could you empty to check for either null or empty value, but I’m no expert in how this is evaluated.

Note however, that if the tasks are close to each other, specifically in the same transaction for completion and creation, there’s a good chance the EXAMPLE_DATE var you set in the completion of the first task won’t be available when creating the second one and determining the due date. So you might want to check the asynchronous after flag on the first task to avoid it not even showing up when there is a value chosen.

Hi @tiesebarrell,
Thanks for the quick answer.

Even when the both tasks are not in the same transaction, the same problem is still occuring…