RabbitMQ Firehose Tracing Debug Plan Prompt

You are a senior platform engineer who has used RabbitMQ's firehose tracer and the `rabbitmq_tracing` plugin to solve "the message vanished" and "it went to the wrong queue" mysteries. Help me capture the broker's-eye view of what actually happened to my messages.

I will provide:
- The symptom: messages published but never consumed, routed to the wrong queue, silently dropped, or dead-lettered unexpectedly [DESCRIBE]
- The topology involved: exchange types, bindings, routing keys, and any policies (alternate exchange, DLX, TTL) that could redirect a message [DESCRIBE]
- The vhost, and roughly the message rate on the affected exchange (so we size the trace safely) [DESCRIBE]
- What the application logs claim happened vs what consumers actually saw [DESCRIBE]

Your job:

1. **Choose the right tracing tool** — explain the difference between the low-level firehose (`rabbitmqctl trace_on`, which republishes every message to `amq.rabbitmq.trace`) and the `rabbitmq_tracing` plugin (a managed UI/file tracer built on the firehose with capture filters). Pick the one that fits the symptom and the message rate.

2. **Read publish vs deliver events** — clarify that firehose emits `publish.*` (message entering an exchange) and `deliver.*` (message leaving a queue to a consumer) events, each carrying the exchange, routing key, and headers. Show how comparing the two answers "did it route at all?" vs "did it route but never get delivered?".

3. **Trace safely under load** — the firehose duplicates every matching message, so it can double broker load and fill a trace queue fast. Design a bounded capture: enable it briefly, filter to the specific exchange/vhost, cap the trace queue with `max-length`/TTL, and turn it off immediately after reproducing. Never leave the firehose on in production.

4. **Correlate the trace with topology** — line up the captured routing key and exchange against the actual bindings (`rabbitmqctl list_bindings`) to see whether the binding you think exists really does, whether an alternate exchange caught an unroutable message, or whether a DLX/TTL policy re-routed it.

5. **Distinguish the failure classes** — from the trace, separate: never published (nothing in firehose = client-side problem), published but unroutable (publish event, no matching binding, possibly to an AE), routed but not delivered (deliver event never fires = consumer/queue issue), and delivered then dead-lettered (deliver + later DLX publish).

6. **Prove the fix** — after changing a binding, policy, or client, re-run the same bounded trace to confirm the message now takes the intended path, then disable tracing and clean up the trace queue.

Output as: (a) which tracer to use and the exact enable/filter/disable commands, (b) how to read publish vs deliver events for this symptom, (c) the correlation steps against bindings and policies, (d) the failure-class decision (where the message actually died), and (e) the verification trace.

The firehose republishes every matched message and can double broker load or fill a trace queue quickly. Enable it only long enough to reproduce, bound the trace queue with max-length/TTL, and always `trace_off` when done — a forgotten firehose is a production hazard.