bpm: a process-instance listing resolves every activity in three queries

[delchev]

What

BpmService.getProcessInstances resolved each instance's activity id one instance at a time - getActiveActivityIds, a JobQuery and a TimerJobQuery, three statements apiece (#7212). GET /services/bpm/bpm-processes/instances is unbounded, and the Monitoring shell's Overview polls it with no key every 30 s, so a tenant with a few hundred running instances paid 3N statements per poll.

The resolution now happens for the whole listing at once, in BpmProviderFlowable.getProcessInstanceActivityIds(List<ProcessInstance>):

• one ExecutionQuery over all the listed ids (processInstanceIds + onlyChildExecutions, tenant-scoped), filtered to the active executions - the flag is not a query criterion, so it is read off the returned rows, which keeps a scope execution (a subprocess or multi-instance parent) from being reported as a second activity;
• the two job queries over the current tenant - Flowable's job queries take a single process-instance id, so the tenant is the narrowest batch filter available - matched against the listed ids in memory.

The evidence and the answer are unchanged, including a step parked between retry attempts that only its own timer job names (#7193). The single-instance path (/instance/{id}, the diagram) keeps its targeted queries.

Tests

BpmProviderFlowableActiveActivitiesTest, against a real in-memory engine:

• the batch answers a parked step, an untried async step and a wait state in one call;
• an instance outside the listing is never answered for, though the job queries read the whole tenant;
• an empty listing asks the engine nothing;
• the query count does not grow with the listing - 2 instances and 8 instances both cost exactly 3 queries, read back from H2's INFORMATION_SCHEMA.QUERY_STATISTICS. That is the regression this fix is about.

mvn -pl components/engine/engine-bpm-flowable test - 35/35 green.

Note

The nit from the issue is fixed too: both in-memory engine tests meant DB_CLOSE_DELAY=-1, not 1000.

While here: the limit: 100 the AngularJS Processes view sends is not a parameter the endpoint declares, so it is dropped on the floor - capping the call would not have helped, which is why this batches instead.

Fixes #7250

🤖 Generated with Claude Code