Fix RabbitMQ Queue Deleted Between Consecutive Publishes (2026)

The AMQP close-reason, initiated by peer error means the RabbitMQ broker forcibly disconnected your client because it detected a severe problem with the queue your client was trying to interact with, specifically that it disappeared unexpectedly.

This usually happens when the queue’s definition is being modified or deleted by another process while your publishing client is still connected and trying to send messages to it. The broker, seeing the queue vanish, cleans up the connection to prevent further errors.

Here are the most common culprits and how to fix them:

Manual Deletion via Management UI/CLI: Someone is manually deleting the queue through the RabbitMQ Management UI or the rabbitmqctl command-line tool while your application is running.
- Diagnosis: Check the RabbitMQ Management UI’s "Overview" or "Queues" tab for recent delete events. Use rabbitmqctl list_queues and rabbitmqctl list_exchanges periodically to see if the queue or its associated exchange exists. If you have audit logs enabled (e.g., via a plugin), review them for delete operations.
- Fix: Educate your team about the implications of manually deleting queues that are in active use. If the queue needs to be recreated, ensure your application can handle a temporary unavailability and reconnect, or implement a robust queue creation mechanism. For example, if using pika in Python, ensure your channel creation logic retries or handles channel.queue_declare errors gracefully.
- Why it works: This prevents the root cause – the manual deletion – by ensuring the queue is only deleted when it’s truly no longer needed and no clients are actively publishing or consuming.
Automated Cleanup Policies (TTL): An Exchange or Queue TTL (Time To Live) policy is configured to automatically delete the queue after a certain period of inactivity or message expiration. If your publishing rate drops below the threshold for deletion, the queue might be removed.
- Diagnosis: Inspect the queue’s arguments in the Management UI or via rabbitmqctl examine_queue <queue_name>. Look for x-expires (queue TTL) or x-message-ttl (message TTL that can indirectly cause queue expiration if all messages expire).
- Fix: Adjust the TTL settings. For instance, to prevent a queue from expiring after 1 hour of inactivity, set x-expires to a much higher value or to 0 (which means never expire). In pika, this would look like:
```
channel.queue_declare(queue='my_queue', durable=True, arguments={
    'x-expires': 86400000 # 24 hours in milliseconds, or 0 for never
})
```
- Why it works: By increasing the expiration time or disabling it, you ensure the queue persists for a duration that accommodates your publishing patterns, preventing premature deletion.
Application Logic Redeployments/Restarts: If your application is redeployed or restarted, and its queue declaration logic is not idempotent or it explicitly deletes queues before declaring them, this can cause the issue. A common pattern is channel.queue_delete followed by channel.queue_declare.
- Diagnosis: Review the application code responsible for declaring queues. Look for explicit queue_delete calls before queue_declare. Check deployment scripts and orchestration configurations for any commands that might be deleting queues.
- Fix: Ensure your queue_declare calls are idempotent. The queue_declare method in most AMQP clients is inherently idempotent; it will create the queue if it doesn’t exist or return information about the existing queue if it does. Remove any explicit queue_delete calls that precede queue_declare unless you have a very specific, carefully managed reason.
```
# Avoid this if queue_declare is idempotent:
# channel.queue_delete(queue='my_queue')
channel.queue_declare(queue='my_queue', durable=True) # This is usually sufficient
```
- Why it works: Idempotent queue_declare ensures the queue is always present or created if missing, without needing to explicitly delete it first, thus avoiding a race condition during redeployment.
Misconfigured Cluster Erlang Node: In a clustered RabbitMQ setup, if one node goes down or is restarted, and there’s a misconfiguration in how queues are managed across nodes (e.g., non-mirrored queues on a node that’s taken offline), the queue might appear deleted to clients connected to other nodes.
- Diagnosis: Check the RabbitMQ cluster status using rabbitmqctl cluster_status. Ensure all nodes are visible and healthy. Review your HA policies for mirrored queues. If queues are not mirrored, ensure the node they reside on is always available.
- Fix: Implement High Availability (HA) for your queues by using mirrored queues. Configure your queues with x-queue-master-locator: client-local or random and ensure they are mirrored across multiple nodes. For example, when declaring a queue in pika:
```
channel.queue_declare(queue='my_ha_queue', durable=True, arguments={
    'x-message-ttl': 60000, # Example: 1 minute TTL for messages
    'x-expires': 3600000,   # Example: Queue expires after 1 hour if idle
    'x-queue-mode': 'lazy',
    'x-ha-policy': 'all'    # Or 'exactly' with a count, or 'nodes' with a list
})
```
  The x-ha-policy: all argument tells RabbitMQ to mirror the queue to all nodes in the cluster.
- Why it works: Mirroring ensures that if one node fails, other nodes have a replica of the queue, so clients can seamlessly switch to a healthy node without the queue appearing to be deleted.
External Orchestration Tools (Kubernetes, Nomad): If your RabbitMQ instances are managed by an orchestration platform, the platform’s lifecycle management might be inadvertently deleting queues. This could be due to pod restarts, service updates, or cleanup jobs.
- Diagnosis: Examine the configuration of your orchestration platform. Look for any jobs, controllers, or operators that interact with RabbitMQ resources or might be designed to clean up stale resources. Check the logs of the orchestration agent on the RabbitMQ nodes.
- Fix: Adjust the orchestration configuration to either prevent automatic deletion of RabbitMQ queues or to ensure queues are recreated reliably after an orchestration event. This might involve defining persistent storage for RabbitMQ data or using specific annotations/labels to exempt queues from cleanup policies. Ensure your RabbitMQ deployment strategy is robust.
- Why it works: By aligning the orchestration lifecycle with RabbitMQ’s expected state, you prevent external processes from terminating queues unexpectedly.
Resource Exhaustion on Broker: In rare cases, if the RabbitMQ broker is under extreme memory or disk pressure, it might start aggressively garbage collecting resources, including queues that it deems "less critical" or that have expired in its internal state, even if TTLs are set high.
- Diagnosis: Monitor the RabbitMQ broker’s resource usage (memory, disk, file descriptors, network connections) using rabbitmqctl status and system-level tools (top, htop, df). Check RabbitMQ logs for any indications of resource warnings or errors.
- Fix: Scale your RabbitMQ cluster vertically (more RAM/CPU) or horizontally (more nodes). Optimize your message processing to reduce the load on the broker. Ensure sufficient disk space and configure appropriate memory alarms in rabbitmq.conf:
```
# Example rabbitmq.conf settings
vm_memory_high_watermark.relative = 0.8 # 80% of available RAM
# or vm_memory_high_watermark.absolute = 2GB
disk_free_limit.absolute = 500MB
```
- Why it works: Providing adequate resources prevents the broker from reaching critical states where it might automatically prune queues as a survival mechanism.

The next error you’ll likely encounter after fixing this is ChannelClosedByBroker: 404 NOT_FOUND - no queue 'your_queue_name' in vhost '/' if your client attempts to publish again before the queue is re-declared or if the deletion process was more complete.