RabbitMQ Messaging

Pathrule3 Rules • 2 Memories • 1 Skill

RabbitMQ separates exchanges, queues, bindings, delivery acknowledgements, publisher confirms, and consumer credit, so a message can be routed nowhere, accepted but not durably replicated, redelivered after work, or trapped in an immediate retry loop. This pattern constrains topology declaration, idempotent consumption, and bounded retries; it records publisher outcome and prefetch decisions and provides a delivery-failure verification workflow. It differs from Kafka by focusing on broker routing and per-message acknowledgement to queues rather than replayable partition logs and consumer offsets.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

verify-rabbitmq-delivery-semantics

src/

messaging/

Declare topology as versioned application infrastructure

Confirm publish outcome and handle unroutable messages

consumers/

Acknowledge only after durable, idempotent completion

Prefetch is per-consumer in-flight work capacity

ops/

rabbitmq/

Retries move through bounded stages

Rules

Declare topology as versioned application infrastructure/src/messaginghighstrictCreate exchanges, queues, bindings, durability, arguments, and ownership explicitly and detect incompatible changes before traffic.

1	RabbitMQ entities are durable shared state whose declarations must agree. A copied queue name or changed argument can route data incorrectly or fail only when a new process starts against an existing broker.
2
3	- Declare exchanges and queues from one topology module or infrastructure workflow with stable names, types, durability, and environment ownership.
4	- Bind each queue with the exact routing keys it consumes and test an unroutable key; do not assume publishing success means a queue matched.
5	- Treat queue argument changes such as dead-lettering, expiry, priority, or type as migrations that may require a new queue and controlled drain.
6	- Separate application queues by workload ownership and retry behavior rather than binding unrelated consumers to one broad shared queue.
7
8	See /ops/rabbitmq for the adjacent decision or procedure that completes this constraint.

Acknowledge only after durable, idempotent completion/src/consumershighstrictProcess under stable message identity and acknowledge after the business transition and required effect record are committed.

1	A consumer can lose its connection after committing work but before acknowledgement, causing redelivery. Acknowledging before commit creates the opposite failure: the broker removes work the application never finished.
2
3	- Require a stable message or operation ID and make the domain transition return the prior outcome on redelivery.
4	- Validate schema, authorization context, and supported version before starting expensive work or opening a transaction.
5	- Acknowledge after local durable completion; reject or dead-letter permanent invalid messages without requeueing them indefinitely.
6	- On transient failure, release according to the retry topology and preserve attempt and original identity without creating a new logical command.
7
8	See /src/messaging for the adjacent decision or procedure that completes this constraint.

Confirm publish outcome and handle unroutable messages/src/messaginghighstrictUse publisher confirms and routing failure handling before marking an outbox or command as delivered to the broker.

1	Opening a channel and sending bytes does not prove that the broker accepted and routed a durable message. Connection loss around publish creates an ambiguous outcome that needs idempotent retry.
2
3	- Publish persistent messages to durable topology when durability is required and wait for publisher confirmation before advancing local delivery state.
4	- Use mandatory routing or an alternate path and treat a returned unroutable message as configuration failure, not successful delivery.
5	- Bound outstanding confirms and channel buffers so a fast producer respects broker backpressure instead of accumulating memory.
6	- Reconnect by recreating channels, confirm state, consumers, and topology through one owner; a channel is not safe to reuse after protocol-level failure.
7
8	See /ops/rabbitmq for the adjacent decision or procedure that completes this constraint.

Memories

Prefetch is per-consumer in-flight work capacity/src/consumersSet credit from task cost, concurrency, memory, downstream pools, and fairness rather than maximizing throughput blindly.

1	Prefetch controls how many unacknowledged deliveries a consumer can hold. A large value can strand work on a slow worker and overwhelm database or HTTP dependencies; a value of one can underuse parallel capacity.
2
3	- Choose prefetch with the consumer's actual parallelism and maximum memory per message, not just average processing time.
4	- Keep in-flight database and remote calls within their own pool limits so RabbitMQ credit does not create a larger hidden concurrency queue.
5	- Use separate queues or consumers for workloads with very different duration and priority instead of relying on one prefetch value for all.
6	- Observe unacknowledged messages, processing latency, redelivery, consumer utilization, and queue age before changing credit.
7
8	See /ops/rabbitmq for the rule or workflow that puts this decision into practice.

Retries move through bounded stages/ops/rabbitmqUse delayed retry tiers and a terminal dead-letter queue so transient failures back off and permanent failures become inspectable.

1	Immediate requeue returns the same poison message to active consumers with no delay, consuming CPU and dependency capacity while making no progress.
2
3	- Classify validation, unsupported version, authorization, and impossible domain state as permanent failures that go directly to a terminal path.
4	- Route transient failures through bounded delay tiers that preserve original message identity, reason, and attempt count.
5	- Cap total attempts and age, then dead-letter with enough context to diagnose and replay after repair without exposing sensitive payloads broadly.
6	- Provide an operator workflow that validates current code and data before replay and uses the same idempotent consumer path.
7
8	See /src/consumers for the rule or workflow that puts this decision into practice.

Skills

verify-rabbitmq-delivery-semantics/rootProve routing, confirms, acknowledgements, retries, dead letters, redelivery, and recovery under broker and consumer failure.

1	---
2	name: verify-rabbitmq-delivery-semantics
3	description: Verify a RabbitMQ topology, publisher, or consumer change before production traffic.
4	---
5
6	# Verify Rabbitmq Delivery Semantics
7
8	Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result.
9
10	1. Publish valid, invalid, oversized, unknown-version, and unroutable messages and inspect exchange, binding, return, confirm, and queue outcomes.
11	2. Terminate the consumer before work, during the transaction, after commit, and before acknowledgement; prove redelivery is harmless and no completed work is lost.
12	3. Fail the dependency with transient and permanent errors and confirm bounded delay, attempt metadata, terminal dead-lettering, and no immediate hot loop.
13	4. Throttle consumers and broker connections to observe prefetch, unacknowledged count, backpressure, memory, queue age, and fair distribution.
14	5. Restart broker nodes and client connections, then verify topology, channels, confirms, consumers, and in-flight operation identities recover through one controlled path.
15
16	## Exit criteria
17
18	The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks.

Why this pattern

AI agents often publish without confirming routing, acknowledge before committing work, requeue permanent failures forever, or set prefetch without considering task cost.

Built for Backend teams using RabbitMQ for commands, work queues, integration events, or delayed processing.

Keeps your assistant from:

Silently dropping an unroutable published message
Losing work by acknowledging before durable completion
Creating a hot poison-message redelivery loop
Overloading a consumer with more unacknowledged work than it can process

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25