Shopware Messenger: Uncertain behavior of message cancellations on worker shutdown

Answer to the question

When a Shopware worker exceeds its messenger.worker.time_limit, the operating system kills the process. The Messenger component does not send a cancellation signal to the database or to the handler, so any in‑flight transaction remains open until the process terminates. The message that was being processed is left unacknowledged. On the next worker start the message is fetched again and retried according to the retry middleware’s configuration.

Messages are transferred to the failure transport only after all retry attempts defined by the messenger.retry middleware have been exhausted, or when an exception is marked as non‑retryable in the retry configuration. The default max_retries is 3, so a long‑running job can be retried up to four times (initial try + 3 retries) before it ends up in the failure queue.

Hooks and configuration for graceful cancellation

• WorkerStoppingEvent: Symfony Messenger publishes this event when the worker is about to be stopped. By subscribing to it you can set a flag or trigger cleanup logic that your handler checks periodically. This is the only built‑in hook for signalling cancellation to a long‑running handler.
• No automatic transaction rollback is performed by Messenger; you must rely on your ORM or database layer to roll back on process death.
• Custom middleware can be added to abort work early when WorkerStoppingEvent is detected, but care must be taken to avoid race conditions.

Adjusting the retry limit to balance reliability and idempotency

1. Open config/packages/messenger.yaml.
   • To change the global retry limit:

     messenger:
         retry:
             max_retries: 5
     

   • To override per transport:

     messenger:
         transports:
             async:
                 options:
                     retry: 5
     

2. Set messenger.failure_transport to a dedicated queue (e.g., failure) so you can inspect failed messages separately.
3. Design handlers to be idempotent or to detect already‑processed work. If idempotence is not possible, keep max_retries low (1–2) to reduce duplicate execution.
4. For very long jobs, consider a separate queue with a larger time_limit and add a WorkerStoppingEvent subscriber that aborts the job early when a shutdown is imminent.

Practical verification steps

1. Create a dummy handler that logs start/end and sleeps for longer than the configured time_limit.
2. Run bin/console messenger:consume async and observe the process exit after the time limit.
3. Check that the message is retried until max_retries is reached, then appears in the failure transport (e.g., run bin/console messenger:failure:consume --limit=1 to fetch it).
4. Add a WorkerStoppingEvent subscriber that sets a global flag; modify the handler to check this flag; verify that the flag is set when the worker is shutting down.

Missing diagnostic detail

To tailor the recommendation further, could you confirm which transport you are using (e.g., async vs a custom transport) and whether you rely on Doctrine transactions in your handlers?