@andrew-demb I forgot to text earlier but even now for the record and anyone else wasting time on this.

Root Cause: AMQP Heartbeat Loss During Long-Running Message Handlers

I spent a good amount of time debugging this exact issue and finally traced the root cause. Sharing here because the error message is genuinely misleading and there's very little documentation connecting these dots.

Why There's No "Real Exception"

There isn't one. RejectRedeliveredMessageException is not hiding an underlying error — it is the error, but the cause is invisible because it happens at the AMQP protocol level, not in your PHP code.

Here's what actually happens:

1. Your consumer picks up a message from RabbitMQ
2. Your handler starts processing — maybe it makes an HTTP request, calls an external API, runs a slow database query, or does any blocking I/O
3. While your PHP code is blocked waiting for that operation to complete, the AMQP connection goes idle
4. RabbitMQ sends heartbeat frames to check if the consumer is still alive
5. The PECL amqp extension is single-threaded — it can only respond to heartbeat frames during AMQP API calls, not while your PHP code is busy doing something else
6. After missing 2 heartbeat cycles, RabbitMQ declares your connection dead and closes it
7. Messages that were prefetched by your consumer get redelivered to another consumer (or the same one after reconnecting) with the AMQP redelivered flag set to true
8. RejectRedeliveredMessageMiddleware sees this flag and throws RejectRedeliveredMessageException before your handler is ever invoked

That's why you see no application-level exception — your handler code never runs on the redelivered message. The middleware intercepts it first.

The Timing Math

The critical relationship is:

handler_max_execution_time < heartbeat_timeout

RabbitMQ considers a connection dead after heartbeat * 2 seconds of silence (heartbeat frames are sent every heartbeat / 2 seconds, and 2 missed frames = dead).

Example with default/common settings:

How to Fix It

1. Reduce your handler's maximum blocking time

This is the most important fix. If your handler makes HTTP calls, set explicit timeouts:

// Symfony HttpClient — per request
$response = $this->httpClient->request('POST', $url, [
    'timeout' => 20,        // max idle time between data chunks
    'max_duration' => 25,   // absolute max time for the entire request
    'body' => $payload,
]);

// Or configure on the scoped client (recommended)
// config/packages/framework.yaml
framework:
    http_client:
        scoped_clients:
            my_callback.client:
                timeout: 20
                max_duration: 25

timeout controls idle time (no data received), max_duration caps the total request time regardless of activity. Use both.

2. Tune your AMQP transport DSN

MESSENGER_TRANSPORT_DSN=amqp://user:pass@rabbitmq:5672/%2f/messages?heartbeat=20&connect_timeout=5&read_timeout=10&confirm_timeout=5

Parameter guide:

The golden rule:

handler_max_blocking_time  <  heartbeat * 2  (dead connection threshold)
read_timeout               >= heartbeat      (avoid idle timeout between heartbeat frames)

With the example above: handler max = 25s, dead connection = 40s, read_timeout = 10s > heartbeat/2 = 10s. Everything fits.

3. Consider prefetch_count

If you run multiple workers consuming from the same queue, set prefetch_count=1 on transports with potentially slow handlers. This limits the blast radius — if a consumer's connection dies, only 1 message is stuck in limbo instead of many.

What About --keepalive?

Symfony 7.2+ added a --keepalive option to messenger:consume, but as of today it only supports Beanstalkd, Amazon SQS, Redis, and Doctrine transports. AMQP is not supported. The keepalive mechanism works by resetting delivery timestamps on the transport side, but for AMQP the problem is at the TCP/heartbeat level which this doesn't address.

There is a newer pure-PHP transport (jwage/phpamqplib-messenger) that uses php-amqplib instead of the PECL extension and handles heartbeats in a separate I/O loop — meaning heartbeats would continue during message processing. However, it's still pre-1.0 (0.9.0 as of writing) and has some limitations (e.g., cannot consume multiple transports in one process). Worth watching for the future — the roadmap is to integrate it into Symfony core for 7.4 LTS.

Common Scenarios That Trigger This

Any blocking operation in your handler that exceeds the heartbeat window:

• HTTP callbacks/webhooks to external services — slow merchants, timeouts, proxy failures
• External API calls — payment gateways, notification services, third-party integrations
• Heavy database operations — large imports, complex queries, lock waits
• File processing — large uploads, PDF generation, image processing
• DNS resolution — slow or failing DNS can add unexpected seconds

Quick Diagnostic Checklist

If you're seeing RejectRedeliveredMessageException:

1. Check your heartbeat value in the transport DSN (if not set, it uses the RabbitMQ server default, often 60s)
2. Look for slow operations in your handler — check HTTP client logs for response times
3. Compare: is the slowest handler execution time > heartbeat * 2?
4. If yes → reduce handler blocking time and/or increase heartbeat
5. If no → check for other causes: network partitions, RabbitMQ node failures, consumer OOM kills

Hope this saves someone the hours I spent staring at a stack trace that told me nothing useful.