NPE possible in AuthorizationCommandChecker#checkTaskPermission

[J-Henke]

Hello,

in org.camunda.bpm.engine.impl.cfg.auth.AuthorizationCommandChecker#checkTaskPermission I received a NPE as our TaskEntity had an executionId but did not have an execution.

See

https://github.com/camunda/camunda-bpm-platform/blob/0e3639e2d5b6316b19b8b66a8938889614e5e6ed/engine/src/main/java/org/camunda/bpm/engine/impl/cfg/auth/AuthorizationCommandChecker.java#L411

Best regards Jan

[tmetzke]

Hi @J-Henke,

thanks for bringing this up 👍

As far as we are aware, this does not occur in any common setup or use case. Thus, could you provide some more detail regarding your setup and in which situation this occurs?

• Which environment are you using (embedded engine, shared engine, Spring (Boot), ...)?
• Does this happen regularly or just occasionally?
• Can you determine specific prerequisites for this to happen (execution in a job, parallel execution, multi-instance)?
• Can you attach a full stacktrace so we can see where you are coming from with the execution?

If you can describe or provide a reproducible setup, it will be easier to determine where the issue is coming from. This will then also speed up root-causing and potentially fixing the situation. The more specific your details, the better 🙂

Cheers, Tobias

[J-Henke]

Hi Tobias,

it happened in a Spring Boot application - so far only once. Only a single instance of the app is running. I can post only a part of the stacktrace:

class java.lang.NullPointerException occurred in current ReST call java.lang.NullPointerException: Cannot invoke "org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.getProcessDefinition()" because "execution" is null at org.camunda.bpm.engine.impl.cfg.auth.AuthorizationCommandChecker.checkTaskPermission(AuthorizationCommandChecker.java:411) at org.camunda.bpm.engine.impl.cfg.auth.AuthorizationCommandChecker.checkReadTaskVariable(AuthorizationCommandChecker.java:396) at org.camunda.bpm.engine.impl.cmd.GetTaskVariableCmd.checkGetTaskVariable(GetTaskVariableCmd.java:72) at org.camunda.bpm.engine.impl.cmd.GetTaskVariableCmd.execute(GetTaskVariableCmd.java:57) at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:28) at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:110) at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:72) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:70) at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:70) at org.camunda.bpm.engine.impl.interceptor.CommandCounterInterceptor.execute(CommandCounterInterceptor.java:35) at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33) at org.camunda.bpm.engine.impl.TaskServiceImpl.getVariable(TaskServiceImpl.java:251)

Best regards Jan

[tmetzke]

Hi @J-Henke,

thanks for those first details.

We are not aware of any such issue with the Spring Boot starter. It might be related to the configuration of your Spring Boot application and/or how you invoke the getVariable method of the task. It could be an issue of data visibility regarding the underlying database and the transactions used by the engine and your Spring Boot application. If you haven't done so already, also consult our Spring Boot guide regarding configuration.

Since the issue tracker itself is meant for feature requests or explicit bug reports that are clearly related to our code base, I would like to ask you to do the following:

• Post your issue with as many details (application configuration, an example process, the application code that leads to the unexpected behavior if applicable) as possible in our C7 user forum. The community is very experienced with Spring Boot setups and might be faster in pointing you to the root cause of the behavior you see.
• If this clearly is a bug in our code (ideally with a reproducible setup), feel free to reopen the issue here or create a new one.

Cheers, Tobias