Hey StephenOTT,

thanks for bringing this up, we will have a closer look at this and get back to you with feedback as soon as possible.
Please note that due to current preparations for the next minor release of the Camunda Platform this might take a bit longer than usual.

Best,
Tobias

Hey StephenOTT,

sorry for the delay and thanks again for bringing this up.

I adjusted the description a bit and also did some more digging into the code to see where this behavior originates.
We already have a flag that allows to decide if the form key should be initialized and thereby the expression should be evaluated or not. This is currently enabled for most query use cases concerning user tasks.

I will move this to decision-making. You can follow the progress in this ticket as usual.

Thanks again for bringing this to our attention.

Best,
Tobias

Hey StephenOTT,

one follow-up question we would have on that issue here:
Have you come across a negative real-world impact for such a scenario or is this rather a theoretical issue that you observed?

Why is that important?
Making the API configurable in that regard introduces more complexity of course. Also, we have not encountered any real-world impact for that part so far. Getting more input on that from your side would therefore help us determining the impact the behavior currently has and which direction to go with this.

Reasoning on the status quo
The form key is always initialized at the moment because it is part of the Task interface, so most people will expect it to be there by default. 

Thanks for your input on this.

Best,
Tobias

Hey StephenOTT,

as we haven't heard back from you so far, I am closing this ticket due to inactivity for now.
That being said. please simply reopen here if you have more input or would like to further discuss this topic.

Thanks and best,
Tobias

The real world negative impact in in a scaled deployment with "citizen modellers" which will deploy BPMNs of their choosing: They will using expressions for the form key to define a specific form. (part of making BPMNs configurable and removing the need to re-deploy for something as basic as a form change).  As a result you end up with excessive queries on expressions.  

I agree that people would expect the key to be there because it is part of the interface: I have to go back and check, but does the expressions re-eval for every expression supported field?  (I don't think they do).  Example the Task Name, or the Assignee field is not re-eval'ed on every GET.  But form key is re-evaled.

@Tobias ping for reopen

Hey StephenOTT,

sorry for the delay.

Re-evaluation of the expression on every request is a good hint, this is something I will look into to assess how much effort that could be.
I will reopen and keep you posted.

Best,
Tobias

Hi StephenOTT,

I just wanted to keep you up-to-date on my findings.
I would agree that - as far as I can see - all task attributes that allow expressions are evaluated once at task creation time in the TaskDecorator. The form key however is not part of this. The form key's expression is rather evaluated on every task query from the REST API as we have already discussed.

I will investigate a bit further why that is the case and if there are any scenarios that require this behavior. In the meantime, if you can think of any valid scenario for evaluating the form key expression not only once at task creation time but rather at any given time later on, I am happy to get input.

Best,
Tobias

Hi StephenOTT,

a final update on that issue from my side.

As stated above, the form key is the only expression-based attribute of the task that is not evaluated once upon creation time of the task but rather on every task query evaluation that has the initializeFormKey option enabled. This is the case for task queries from the REST API.

For the time being, we will keep that behavior for the form key. The dynamic evaluation of the form key allows to for example rename the form within a deployment while keeping a task functioning correctly if its form key expression is re-evaluated based on process instance properties. This would not be possible that easily if the evaluated form key expression is persisted in the task upon creation since there is no API to simply change this value as you can do with for example the assignee.

Regarding the REST API, as said, we need to evaluate the expression and add that value to the task since the form key is part of the interface and people expect it to be there. Furthermore, we do not yet have any evidence of a detrimental performance impact of this practice. We will therefore not take any actions regarding this topic as of now.

As always, we are open to your input on this. If there is factual evidence about this having a negative real-world impact on application performance, please also let us know so we can reconsider this issue. For now, I will close this topic as we will not take any action regarding it.

Best,
Tobias