bpm: the Inbox list omits a task completed while it is being built instead of failing with 500 (#7575)

[NicoleNG18]

Cause

GET /services/inbox/tasks (and /instance/{id}/tasks) lists the tasks with one query and then reads each one again: its identity links, then its process instance. If another session completes a task in between, that read fails in one of two ways:

• Task not found: the tenant validator reports Task with id [..] not found or does not belong to current tenant (the issue's trace).
• Process ended: when the completed task was its process's last, the process instance is gone too, and mapProcessInstance throws a NullPointerException.

Neither exception was caught, so one vanished task failed the whole list with a 500 for everyone loading it at that moment.

Change

This takes the issue's primary option: a task that vanished between the query and its per-task read is treated as gone and omitted.

• Each listed task is mapped through mapListedTask. If a per-task read throws, one tenant-scoped existence query decides what happens. That query is the new isTaskActive(taskId) on BpmProviderFlowable / BpmService, a count() mirroring getTaskActions.
  • Task confirmed gone: it is omitted and logged at DEBUG with the exception.
  • Task still exists: the failure is real, and it propagates exactly as before. Nothing is swallowed.
• Both list endpoints go through the same path.
• I did not take the issue's optional alternative (building the DTOs from the list query's own result): Flowable's Task carries no business key or definition name, so it would mean a new batched process-instance query. That is a larger change than this defect needs.

Verification

• New BpmInboxEndpointVanishedTaskTest: covers the "not found" read, the ended-process NPE, a failure on a still-active task that must still propagate, and the per-instance listing. The existing BpmInboxEndpointSubjectTest and the module suite (56) pass.
• New BpmInboxConcurrentCompletionIT (HTTP-only): it starts 40 single-task processes, then lists the group Inbox continuously while completing the tasks tail-first, and requires every list call to answer 200. Tail-first is deliberate, because each list query then still holds the tasks being completed while the lister walks toward them.
  • Against the unfixed endpoint: 11 of 36 list calls answered 500. The log shows both failure modes (20 "not found" traces, 2 NPEs).
  • With the fix: every call answered 200, and the race was hit and handled 7 times.
• BpmTaskLabelKeyIT and IntentWorkflowStatusIT pass on H2.
• mvn formatter:validate passes after wiping the formatter cache. The release-profile javadoc build of engine-bpm-flowable passes.

Not verified: the PostgreSQL leg.

Fixes #7575

🤖 Generated with Claude Code