fix(bpm): report the step an instance is parked on while an async retry is pending (#7193)

[iliyan-velichkov]

Fixes #7193.

Root cause

Flowable's JobRetryCmd calls executionEntity.setActive(false) when it moves a failed asynchronous job to the timer-job table, and FindActiveActivityIdsCmd collects only activity ids of executions whose isActive() is true. So from the first failed attempt on, the execution is inactive and the pending job is the only remaining evidence of where the instance sits - while getProcessInstanceActiveActivityIds queried nothing but dead-letter jobs, which it maps to negative.

Because BpmnIntentGenerator emits its steps flowable:async, an intent-generated process therefore answered "no step is running" for its whole life: nothing for the Processes viewer or the Monitoring diagram to overlay, and no way for an application to tell its own users which step a record's process is on.

The change

Executable and timer jobs now count towards positive alongside the active executions, merged by the higher of the two counts rather than by their sum. That matters: ContinueProcessOperation marks the execution active before it creates the async job, and a boundary event's own child execution stays active beside its timer job - so summing would render every pending asynchronous step, and every boundary timer, as a "2" badge on both diagram overlays. Dead-letter jobs stay negative, exactly as before, and a job bound to no flow element (an asynchronous variable write, a process-instance migration) no longer becomes a literal "null" key in the answer.

Two sites sharing the same root cause come with it:

• getProcessInstanceImage highlighted from the same getActiveActivityIds call, so GET /bpm-processes/diagram/instance/{id} had nothing to mark either.
• The Monitoring shell's Retry action - moveDeadLetterJobToExecutableJob hands the job back to the executor without reactivating the execution, so a click made both badges disappear and the step looked finished.

And ProcessInstanceData.activityId (the issue's second symptom, "activityId": null on GET /bpm-processes/instances) is resolved the same way instead of read off the root process-instance execution, where Flowable always leaves it unset. The field is singular, so it carries the sole occupied activity and stays null for a fan-out, where /active is the answer.

Deliberately out of scope: createSuspendedJobQuery() (suspension moves both job tables, but the platform exposes no suspend/activate path, so no instance is ever in that state) and getProcessDefinitionActiveActivityIds, which queries executions without the isActive filter and therefore already reports parked steps.

One knowing limitation, noted in a code comment rather than passed over: max undercounts if a single element ever hosts both a waiting token and a parked one - an asynchronous task behind a loop or a fan-in. Counting exactly would take a per-activity execution query on an endpoint both UIs poll.

Tests

BpmProviderFlowableActiveActivitiesTest drives a real in-memory Flowable engine with the async executor off, so there are no threads and no sleeps: ManagementService#executeJob runs the attempt on the calling thread and Flowable's own failed-job listener then applies the retry decision in its own transaction. Five states: a pending job (guarding the double count), parked between retry attempts, dead-lettered, retried out of the dead letter, and a plain wait state.

BpmActiveActivitiesIT publishes a throwing client delegate on a flowable:async step with an R5/PT1H cycle (load-bearing - without a cycle the executor dead-letters the job within half a minute and the state under test would expire mid-test), waits for the parked timer job, and asserts that job's exception message carries the delegate's own text, so the test cannot pass on a job that never resolved the compiled class. It then asserts both HTTP answers. Untagged, so it runs in the per-PR smoke gate; ~21 s.

Both suites were confirmed to fail without the production change and pass with it. Also green locally: the module's full unit suite, and JavaBpmnIT / BpmTaskLabelKeyIT / JavaDelegateInjectionIT / BpmnModelApiIT (the integration tests exercising the changed instance mapping). formatter:validate is clean and the -P release javadoc build reports no errors.

🤖 Generated with Claude Code