Federation not working between RabbitMQ 3.8.9 and 3.13.7 during migration

[kumrurumeysa]

Describe the bug

Hello RabbitMQ team,

I am trying to upgrade and migrate from RabbitMQ version 3.8.9 to 3.13.7.

After setting up both versions, I tested message migration using Shovel. It worked, but our requirement is that the messages remain available in both the source and destination RabbitMQ instances during the transition. We want to avoid any downtime.

Therefore, I attempted to use Federation instead. However, Federation did not work correctly between these versions. The link status shows as "running," but messages are not federated.

I understand that RabbitMQ 3.13.7 uses quorum queues by default, which might cause compatibility issues. However, even when I created classic queues on both the source (3.8.9) and destination (3.13.7), Federation still failed to work as expected.

I also verified parameters such as durable and other queue settings to ensure compatibility, but the problem persists.

Could you please help clarify:

1. Is Federation officially supported between 3.8.9 and 3.13.7?
2. Is there a stable upgrade path from 3.8.9 that supports Federation or a similar mechanism without causing downtime or data loss?
3. What is the recommended approach for this type of migration?

I would really appreciate your support and guidance on this issue.

Thanks in advance!

Reproduction steps

1. Set up a new rabbitmq.
2. Import json files from old cluster (updated the arguments according to new one)
3. Create federation upstream and policy on the destination (new) rabbitmq.
   ...

Expected behavior

After creating a federation upstream and policy we expected to work federation but it did not.

Additional context

No response

[michaelklishin]

@kumrurumeysa I can clarify that

0. Our team does not use issues for questions, that's what Discussions are for
1. Our team cannot comment on "does not work correctly". We do not guess in this community
2. 3.9.x and 3.13.x are out of community support
3. There is an upgrade compatibility table. A series of upgrades is an option, you must upgrade to the latest patch release in the next series, then enable all stable features flags

our requirement is that the messages remain available in both the source and destination RabbitMQ instances during the transition

If you are hinting at the fact that Blue/Green deployments use queue federation, then I have bad news for you: queue federation does not replicate messages, it moves them, just like Shovel does. Queue federation is consumer-aware in the sense that it won't move any messages if there are local consumers present.

Exchange federation replicates messages, queue federation moves them.

[michaelklishin]

In addition, by far the most common reasons for "federation not working" are

1. A missing policy or a policy that does not match any or the resources you expect to be federated. Links are only started when a policy with federation keys matches some objects
2. The federation plugin is not enabled on both ends
3. Queue federation users expect it to work when there are consumers the upstream. Queue federation won't move any messages when there are local consumers on the upstream, by design. Queue federation consumers use negative consumer priorities

If you want to move message unconditionally, use a shovel. If you want them to be replicated, use exchange federation, to which points 1 and 2 still apply.

[michaelklishin]

I'm not interesting in spending time on "issue reports" with the problem definition of "it does not work" => closing.

Next time take a little bit more time to explain what exactly you did or don't expect much. You get the software for free, support for community-supported series for free, basic guidance even when both of your series are out of community support, and expect our team to spend time guessing? Yeah, right.