Symfony Messenger retry strategy and write idempotency limits

Short answer: no, Messenger's retry_strategy cannot be linked to message uniqueness, and there is no built-in deduplication middleware. The retry loop only controls when a failed message is redelivered (max_retries, delay, multiplier, max_delay); it knows nothing about what your handler did before throwing. The recommended fix is not to deduplicate messages at all — it is to make the write itself idempotent, using machinery your database already provides.

The likely explanation vs. the confirmed facts

Confirmed: Messenger transports (Doctrine, AMQP, Redis) provide at-least-once delivery. The message is only acknowledged after the handler returns without an exception, so a handler that inserted a row and then threw will run again in full on retry. Nothing in the framework tracks partial success.

The likely explanation for why this feels like a missing feature: idempotency is inherently business-specific. A generic dedup middleware would need to know what "already processed" means for your domain, which is why the framework leaves it to you — but "to you" does not have to mean a bespoke dedup store per handler.

Step 1: Wrap the handler's writes in one transaction

If every side effect in the handler is a database write, a single transaction already gives you atomic processing: an exception rolls back the partial work, and the retry starts from a clean state. With Doctrine this is often the default if you flush once at the end; verify you are not flushing mid-handler or mixing transactional writes with non-transactional ones.

Step 2: Stamp an idempotency key at dispatch time

For handlers where rollback alone is not enough, attach a stable key to the message when it is created — never inside the handler, because the handler re-executes on retry and would generate a new key each attempt:

$message = new ImportOrder($orderId, idempotencyKey: Uuid::v4()->toString());
$bus->dispatch($message);

Retries carry the same message instance, so the same key reappears on every attempt. Then enforce uniqueness in the database — either as a natural unique key on the written entity or a dedicated column — and treat a duplicate-key violation as success:

try {
    $em->persist($row);
    $em->flush();
} catch (UniqueConstraintViolationException) {
    // Already processed by a previous attempt — safe to acknowledge.
}

The exact exception class depends on your DBAL version, so confirm it in your installation rather than assuming the name above. This pattern replaces a dedup store: the unique index is the dedup store, maintained atomically by the database.

Step 3: Handle non-transactional side effects separately

There is no Messenger configuration that makes an email send or an HTTP payment call retry-safe. The standard escape is the transactional outbox: write an outbox row in the same transaction as your state change, and let a separate worker perform the external call. If that is too heavy for one boundary call, a small dedup table keyed by the dispatch-time idempotency key is the honest fallback — but it should be one shared table, not one per handler.

What does not work

• Reading the attempt count via the RedeliveryStamp and skipping writes on retry — fragile, and breaks if the first attempt genuinely failed before writing.
• Locks (Symfony Lock, pessimistic DB locks) — they serialize concurrent execution of the same key, which prevents races, but they do not prevent a retried handler from writing twice. They complement a unique constraint; they do not replace it.

Verification

1. Dispatch a message whose handler inserts a row and then throws; watch the transport table and confirm duplicate rows appear without a constraint.
2. Add the unique index, re-run, and confirm the retry completes with exactly one row and no unhandled exception.
3. Log or inspect the envelope across attempts (a test middleware works) to confirm the idempotency key is identical on every retry.
4. Dispatch the same message twice concurrently to confirm the constraint also holds under races.

One detail that would change this recommendation: if your failing side effect is an external API call rather than a database write, say so — the answer shifts from unique constraints to the outbox pattern, and the verification steps differ.