Instance migration for the processes with event subprocess is not possible

[sdorokhova]

Description (required on creation)

When migrating an event subprocess, users can decide if they also map the start event or not.

• If it is not mapped: The event subscription is deleted and re-created during migration. For example for a timer start event, this means that the timer starts counting from the beginning again.
• If it is mapped: The event subscription itself is migrated. For example for a timer, it keeps running by the original definition. For a message, it keeps the original subscription and its message name.

There is one limitation to message events: It is not possible to re-create a message with the same name (due to a technicality in how messages are stored in Zeebe, see #16999 and #25309). So in order to migrate a process with a message event subprocess, the start event must always be mapped. In that sense, if it is not possible to map the start event, users cannot migrate such process instances at all.

The goal of this ticket is to support mapping start events of all event subprocesses.

Steps to reproduce (required on creation)

1. Deploy process with event subprocess
2. Start one instance
3. Deploy another version of the same process
4. Open migration UI for the process instance

Current behavior (required on creation)

It's possible to only map event subprocesses themselves, but not start events. Therefore migration fails with Zeebe error:

ERROR 2024-11-18T13:11:57.847719185Z [resource.labels.containerName: operate] Unable to process operation with id a940ec02-a191-455d-9d43-f5c12070f03f. Reason: Command 'MIGRATE' rejected with code 'INVALID_STATE': Expected to migrate process instance '2251799914721986' but active element with id '<..>' attempts to subscribe to a message it is already subscribed to with name '<..>'. Migrating active elements that subscribe to a message they are already subscribed to is not possible yet. Please provide a mapping instruction to message catch event with id 'Event_0jvg9f0' to migrate the respective message subscription.. Will NOT be retried.

Expected behavior (required on creation)

It is possible to map bot subprocess itself and start event and migration works well.

Environment (required on creation)

• Operate Version: 8.6.2 (may be earlier also)

Rootcause (required on prioritization)

• The UI prevents mapping of sub process start events (except for timers)

Solution ideas

Support mapping all event sub process start events that are supported by Zeebe to events of the same type.

Mapping for these types is already supported:

• timer
• signal
• escalation
• error

Mapping should not be possible for these unsupported types by zeebe (according to https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-coverage/):

• compensation
• conditional

Mapping needs to be added for this type:

• message

Additional context

Incident channel, also contains process examples: https://camunda.slack.com/archives/C081F9YLAF6

Handover Dev to QA (required before manual testing)

• Resources:
• Versions to validate:

The issue will be on main (8.7.x and will be backported to 8.6.x):

8.7.x image: registry.camunda.cloud/team-operate/camunda-operate:branch-fe-25071-message-start-event-migration

8.6.x image: registry.camunda.cloud/team-operate/camunda-operate:branch-fe-25071-message-start-event-migration-8-6

• Release version (in which version this feature will be released)

8.7.0-alpha3

8.6.6

Link to the test case

Links

Pull Requests

Preview Give feedback

1. feat: support message start event mapping for instance migration #25412
   component/operate +1
2. feat: support message start event mapping for instance migration (8.6 backport) #25450
   component/operate +1