New in Symfony 8.2: Messenger Flows (Symfony Blog)

November 11, 2026 • Published by Javier Eguiluz
Symfony 8.2 is backed by:
Many business processes involve several messages: process a podcast, then optimize it, then release it; charge a card, then ship the order, and cancel it if anything goes wrong. In Messenger, these flows are usually built by having each handler dispatch the next message, so the sequence is scattered across handlers and each handler is coupled to the step that follows it.
Inspired by an article comparing Messenger and Ecotone, Symfony 8.2 adds a set of stamps that let you declare these flows when dispatching the first message.
When a handler dispatches a follow-up message, that message starts with an empty envelope. So data like a tenant ID or a trace ID often ends up as a property of every message in the flow, only to pass it along.
In Symfony 8.2, stamps that implement the new PropagatedStampInterface are copied automatically to every message dispatched while handling the message that carries them. In addition, handlers can now get stamps (or the whole Envelope) as arguments after the message:
When a flow involves many messages, debugging it requires knowing which messages belong to it and which message dispatched each one. Symfony 8.2 can add this information automatically with the new identity_stamps option:
When enabled, every message gets a MessageIdStamp with a unique ID that is kept across retries and replays. Messages dispatched by a handler also get a CausationStamp with the ID of the message being handled, and all the messages of the flow share the same CorrelationStamp (the following example uses short IDs for readability; real IDs are 32-character random strings):
As with any other stamp, handlers can get them as arguments (e.g. to add the correlation ID to your logs). The option is disabled by default because it changes the serialized envelopes. It's also required by the Messenger inbox.
The new ChainStamp lets you define the sequence of a flow in a single place. Each message is dispatched only after the previous one has been handled by all its handlers:
The remaining steps travel with the message inside the stamp, so a retried step continues the chain from where it stopped. A step without its own routing goes to the transport that the previous step was received from, so each step is retried independently. If a step fails, the chain stops.
The new DispatchOnFailureStamp defines a message to dispatch when the message it's attached to fails permanently (after all its retries in a worker, or when the exception is thrown in a synchronous dispatch). Combined with chains, you can define compensation logic for the entire flow:
Each step of the chain passes the stamp to the next one, so CancelOrder is dispatched only once, whichever step fails. This stamp also replaces the failure transport: the failed message is only sent to the failure transport when CancelOrder can't be dispatched.
Retries and the failure transport were only available to messages handled by workers. Messages handled with the sync:// transport (e.g. a payment webhook processed during the request) weren't retried, and the retry_strategy and failure_transport options were silently ignored.
In Symfony 8.2, the sync:// transport supports both features with the new retry and failure_transport options:
Failed messages are retried immediately, ignoring the delays of the retry strategy. If the message still fails, it's sent to the failure transport instead of throwing an exception, so you can inspect it with messenger:failed:show and retry it with messenger:failed:retry as usual.
Adding stamps to the messages of scheduled tasks required a custom schedule provider. In Symfony 8.2, the #[AsCronTask] and #[AsPeriodicTask] attributes include a new stamps option. List the stamp class names and, when a stamp needs constructor arguments, map the class to those arguments:
Stamps used when sending messages (such as DelayStamp) only apply when the task goes through a transport (via the transports or use_messenger_routing options).
❤️ Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
💼 Backend Symfony Developer at Constructiva Solutions View Symfony jobs →
€60,000 – €75,000 / year Germany Remote + part-time onsite (Bonn, Germany)
I don't know how you guys crank out that good stuff so fast. Thanks a lot.
🎉 YES 🎉 so no more meddling with HandlerArgumentsStamp and custom middlewares just to achieve this.
Code consumes server resources. Blackfire tells you how
Show your Symfony expertise
Put the code quality back at the heart of your project
Thanks Cyril HERRERA for being a Symfony contributor
1 commit • 6 lines changed
View all contributors that help us make Symfony
Be an active part of the community and contribute ideas, code and bug fixes. Both experts and newcomers are welcome.
Symfony™ is a trademark of Symfony SAS. All rights reserved.