Cross-cutting data attached to a workflow instance by WorkflowExecutionListener should survive process restarts #1645
Description
Activity
- addedjavaPull requests that update java codePull requests that update java code
on Aug 29, 2026 You mean that additional objects associated to workflow instance should be stored? You put the emphasis on the listener, when actually anyone with access to a WorkflowIntance reference can add additional information to the instance.
Yes, I added the emphasis to
WorkflowExecutionListenerbecause the need to store additional data to be survived by JVM came fromopentelemetrymodule, which make use ofWorkflowExecutionListenerto manage OTel spans. I think I should be more generic in the issue's description.The fact is: currently we can not add additional data to be stored during persistence, to be recovered after a recover.
Reacted by Francisco Javier Tirado SartiThis need came originally from this quarkiverse/quarkus-flow#902 (comment) in quarkus-flow project. I created a project to reproduce the behavior, if want to try https://github.com/mcruzdev/flowable.
Reacted by Francisco Javier Tirado SartiYes, the feature is clear.
The problem is to serialize the additional object into the db. That might be possible or not. In any case lets try.
What would you like to be added
Cross-cutting data attached to a workflow instance by
WorkflowExecutionListenershould survive processrestarts when persistence is enabled.
Why is this needed
When a workflow instance is resumed after a JVM restart, any data that lifecycle listeners
previously associated with that instance is lost. This breaks use cases where listeners need
continuity across restarts — such as keeping a distributed trace connected across the full lifetime
of a workflow, maintaining a correlation ID. There is currently no
supported way to preserve this kind of data through a restart without polluting the workflow's own
data model with infrastructure concerns.