In Cockpit, filtering by async activities when modifying instances in a batch is broken

[venetrius]

Environment (Required on creation)

reported and verified in Version v7.22.0-ee
(verified this is not an issue in Version v7.21.0-ee)

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket)

When filtering for process instances in the modify process instances as batch on the process definition runtime view, results are not shown in case all of these three conditions are met:

• ActivityIdIn filter is used
• the activity is async or part of a compensation.
• the process has not been scheduled yet by the executor: job is suspended or executor is suspended or overwhelmed, ( or a race condition, but that would result only in transient inconsistency)

Steps to reproduce (Required on creation)

• Deploy example BPMN: taksWithAsyncGateway.zip
• Suspend Gateway job in Process Instance Definition page
• Start a new process instance
• Select GateWay to cancel process instances
• Verify that no process instance is shown in modify filter

Observed Behavior (Required on creation)

No process instance is shown in modify filter

Expected behavior (Required on creation)

Relevant Process Instances are always shown in Modify Filter even when ActivityIdIn filter is used

Root Cause (Required on prioritization)

Modify operation has been changed to use the historic API, with this change the ActivityIdIn filter has been added to the historic API. This come with a few limitation as historic PI data is only generated when the job is scheduled:

• Tokens on Async Tasks: Tokens sitting on an asyncBefore/asyncAfter task will not yield process instances when using the activityIdIn filter, as no history has been produced yet. Filtering here is effectively racing against the job executor. Given the job executor usually processes faster than a user can apply filters, state changes can impact query results. This filter is most applicable for true wait states (e.g., user tasks, external tasks, timers) rather than transaction boundaries.
• Compensation Scenarios: It is no longer possible to retrieve process instances with the activityIdIn filter on the subprocess "activity". When using activityIdIn filter for compensation scenarios, users need to filter by specific flow nodes rather than the broader subprocess activities.
• Incident Deletion: When an incident is deleted, the incident filters will still return the process instances that previously had an incident. This behavior aligns with the standalone batch operation page and ensures consistency across the application.

Solution Ideas

When ActivityIdIn filter is used join ACT_RU_EXECUTION table to include process instances in the query result that might not have been scheduled yet.

Hints

Links

• https://jira.camunda.com/browse/SUPPORT-24208
• Prototype: fix(webapps): activityIdIn filter returns all relevant instances #4758

Breakdown

Pull Requests

Beta Give feedback

1. fix(webapps): activityIdIn filter returns all relevant instances #4758
   ci:e2e +1
   
2. fix(engine): allow querying for hist pis by async activities #4769
   bot:backport:7.22 ci:all-db +2
   
3. https://github.com/camunda/camunda-bpm-platform-maintenance/pull/1302
4. docs(mig-guide): allow query for hist pis by async activities camunda-docs-manual#1698
   bot:backport:7.22 +1
   
5. [Backport 7.22] docs(mig-guide): allow query for hist pis by async activities camunda-docs-manual#1705
   +0
   

Dev2QA handover

• Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[venetrius]

Hi @tasso94,
Assigning for prioritisation.