-
Bug Report
-
Resolution: Fixed
-
L3 - Default
-
None
Bug description
What are the steps to reproduce your problem ?
- Build a spring boot application with config
camunda:
bpm:
eventing:
task: true
- Build a listener as shown in https://docs.camunda.org/manual/7.11/user-guide/spring-boot-integration/the-spring-event-bridge/ and log the events coming in.
Annotate the event method using
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT, fallbackExecution = true)
instead of
@EventListener - Deploy a process with a usertask and an assignee set.
What is the problem?
Once the engine hits the usertask two events fire:
- create
- create
What would be the expected behavior:
Once the engine hits the usertask two events fire:
- assignment
- create
Root cause
The event listener is asynchronous, i.e. handles the event only after transaction commit.
As the DelegateTask object is the task that is mutated by the engine, its state has changed until then.
On a side note: with such listeners it doesn't make sense to expose setter methods in the event, because they will likely have no effect
Solution outline:
For task and execution listener events, we should publish two types of events:
- A mutable Delegate* event (this is what we currently do)
- An immutable task/execution event that copies the Delegate* properties and exposes only getters
We should document both event types and mention the limitation that the mutable event type can only be used with synchronous listeners.