Introduction

A messaging migration can bring a new RabbitMQ broker online while Shovel still forwards messages to the old one. Publishers and consumers appear healthy, but inter-broker traffic continues landing on the retired cluster, one shovel uses the new destination while another still targets the previous URI, or failures begin only after the old broker is removed because dynamic shovel definitions, policies, and credentials often change at different times.

Treat this as a message-forwarding target problem instead of a generic RabbitMQ outage. Start by checking which source and destination URI an affected shovel actually uses at runtime, because migrations often validate direct application traffic first while broker-to-broker forwarding continues following older shovel definitions.

Symptoms

  • RabbitMQ Shovel still forwards messages to the old broker after migration
  • Applications work, but forwarded queues or exchanges continue filling on the retired cluster
  • One shovel uses the new broker while another still targets the previous URI
  • Delivery failures begin only after the old broker, vhost, or credentials are removed
  • The new broker is healthy, but migrated forwarding paths never use it consistently
  • The issue started after moving RabbitMQ clusters, federation-style flows, or queue-bridging logic

Common Causes

  • The shovel definition still references the old broker URI
  • Runtime parameters or policy-delivered shovel config were updated on one node but not another
  • Credentials were rotated for the new broker, but the destination target itself was not changed consistently
  • A definitions import, automation run, or cluster bootstrap restored the earlier shovel settings
  • One virtual host or shovel group was migrated while another still uses the previous destination
  • Validation confirmed the new broker accepted test publishes but did not verify where live shovel forwarding actually sent messages

Step-by-Step Fix

  1. Capture one affected shovel and record the source URI, destination URI, virtual host, and node or policy source it actually uses, because the live shovel definition determines where forwarded messages really land.
  2. Compare that active forwarding path with the intended post-migration messaging design, because one stale shovel definition can keep inter-broker traffic tied to the retired cluster.
  3. Review shovel definitions, runtime parameters, policy delivery, definitions exports, and automation templates for references to the old broker, because RabbitMQ forwarding behavior can come from both dynamic config and imported broker state.
  4. Check each virtual host, shovel group, and node separately if behavior differs, because migrations often update one forwarding path while another still targets the previous destination.
  5. Update the authoritative shovel definition and configuration source so affected forwarding paths use the intended broker, because standing up the new cluster alone does not retarget existing shovels.
  6. Trigger a controlled message flow and confirm the intended destination broker receives the forwarded traffic, because successful publish and consume activity does not prove the right shovel target handled the handoff.
  7. Verify the old broker no longer receives forwarded messages from migrated shovels, because split messaging paths can remain hidden while both clusters stay reachable.
  8. Review credentials, TLS trust, queue permissions, and reconnection behavior if forwarding still fails, because the destination can be correct while broker trust or authorization still blocks the new path.
  9. Document which team owns shovel definitions, policy distribution, and migration validation so future RabbitMQ cutovers verify the actual runtime forwarding target before retiring the previous broker.