runtimeService no Instances returned

Flowable Engine
1

Later in the workflow processing (in a DelegateExecutionTask which it gets into) I’m trying to see if a workflow has already been started for this document and I’ve been having problems getting back running instances so I dummied it down to right where the workflow is created.

ProcessInstance processInstance =
runtimeService.startProcessInstanceById(processDefinition.getId(), businessKey, props);

log.debug("@@ ProcessInstance = {}", processInstance);
log.debug("@@ Count = {}", runtimeService.createProcessInstanceQuery().count());
log.debug("@@ Size = {}", runtimeService.createExecutionQuery().list().size());

return processInstance;

Workflow runs and starts okay, processInstance has value but
both count and size return 0 and I don’t know why.
I’ve tried a lot of variations and 6.5.0 and 6.4.2 and still getting the same issue.

2

Is this a process that has no wait states?
If so, the process instance will run, but no runtime state will be persisted, as there is no point in which the process instance stops. Which means that the count and list won’t return any results. If you’d use the historyService#createHistoricProcessInstanceQuery it will give you a count of 1 though.

3

Yes, I figured that was the issue already. You are right, the process starts up and runs to completion and I never see any running workflows. It was interesting that the DelegateTask didn’t see any instances even though it was in one. I’m assuming that is because no wait states for the engine to catch up. The future of this workflow will include some event wait states which I assuming will allow the engine to report it correctly. It was also interesting in a small POC to prove this out, when I did get back a ProcessInstance that the call to the variables had no variables in it, I expect the variable that I started the workflow with.

I ended up having to do this but I didn’t expect it.

String fName = (String) runtimeService.getVariableInstance(processInstance.getId(),“fileName”).getValue();

4

Indeed. When the engine encounters a wait state (e.g. a user task or an event receival), the state is persisted and there will be a runtime process instance that is queryable.

The reason for that is to keep the runtime tables small (only the in-flight process instances). The history service always has both finished and unfinished ones though.

Indeed, those variable would only be set if getting the process instance through a query and using #includeVariables (which is not possible in this case). See flowable-engine/modules/flowable-engine/src/main/java/org/flowable/engine/runtime/ProcessInstance.java at main · flowable/flowable-engine · GitHub.