Process the modification command atomically if it is rejected

[saig0]

Description

The modification command can be rejected for different reasons (e.g. element instance is not active anymore). If the command is rejected then we need to ensure that no side-effect is produced (i.e. no records written, no state modified). The command should be processed atomically.

Note that this issue depends on the progress of the engine abstraction topic. We need to roll back the side-effects (i.e. database transaction, records) in the engine if the command gets rejected. But we don't have control over the side-effect in the engine.

Currently, we could only throw an exception to roll back the side effects. As a result, the side-effects are rolled back and the command is rejected. But this would also add the process instance to the blacklist and would make it unusable.

One hacky idea is to create a special exception (e.g. DoNotBlacklistProcessInstanceException) and handle this explicitly in the stream processor to avoid that the process instance being added to the blacklist.

Related to #9420
Related to #9644

Blocked by

• Process a modification command #9639

[korthout]

I think this issue is already done as the capability is already there. The specific usage of this will come with

• Reject the modification command if it exceeds the max message size #9728
• Reject the modification command if the flow scope of an element for activation can't be created #9980 (already in progress)

I'll close it as completed.

@saig0 @remcowesterhoud Please reopen this issue if you think I missed something.