Federation plugin runs into an exception when replicating MQTT v5 bindings due to mqtt_subscription_opts

[sergio-aguilar-tuhh]

Describe the bug

When an MQTT v5 client subscribes to a topic, the RabbitMQ MQTT plugin adds a mqtt_subscription_opts tuple to the binding arguments. The Federation plugin fails to replicate these bindings across nodes due to a serialization issue in AMQP 0.9.1, which does not support this custom tuple. This causes the Federation plugin to crash with a function_clause error, disrupting the federation process.

Error observed in logs:

reason: {function_clause,
         [{rabbit_binary_generator,table_field_to_binary,
              [{mqtt_subscription_opts,1,false,false,0,undefined}],
              ...]}

Reproduction steps

Reproduction steps

1. Set up RabbitMQ with the MQTT and Federation plugins enabled.
2. Configure a federation link between two nodes using the amq.topic exchange.
3. Connect an MQTT v5 client to Node A.
4. Subscribe the MQTT client to a topic, e.g., ground/test.
5. Monitor logs on Node A and Node B for federation errors.

Expected behavior

The Federation plugin should replicate MQTT v5 bindings across nodes without causing crashes or interruptions. MQTT v5 metadata (mqtt_subscription_opts) should either be ignored or properly handled during serialization.

Additional context

• Root cause: The Federation plugin attempts to replicate MQTT v5-specific subscription metadata (mqtt_subscription_opts) using AMQP 0.9.1, which cannot encode this custom tuple.
• Workaround: MQTT v3 clients work correctly since they do not use mqtt_subscription_opts.
• Impact: MQTT v5 subscriptions cannot be federated across nodes, making it impossible to use MQTT v5 in federated environments.

Environment

• RabbitMQ version: 4.0.5 (Docker image: rabbitmq:4.0.5-management)
• MQTT plugin version: 4.0.5
• Federation plugin version: 4.0.5 (same as RabbitMQ version)
• MQTT client: paho-mqtt 2.1.0

[michaelklishin]

@sergio-aguilar-tuhh changing how federation propagates bindings is a big deal, it would not a backwards compatible change, and the federation "data format" has been backwards compatible for some 15 years now.

@ansd what do you think our options are here?

[ansd]

@michaelklishin I described what I think is the best solution in #13040

[ansd]

Closing this discussion in favour of #13040

[sergio-aguilar-tuhh]

Thank you for the quick response, @michaelklishin.

For now, I’ve been exploring a workaround by filtering out mqtt_subscription_opts in the MQTT plugin, but it’s not ideal since it limits MQTT v5 features.

[michaelklishin]

Do you have an example of the mqtt_subscription_opts value that rabbit_binary_generator: table_field_to_binary/1 fails to serialize? Because extending the binary generator is an acceptable option as long as it's a matter of transferring over a binary which the other end of the link would know how to handle.

[sergio-aguilar-tuhh]

The mqtt_subscription_opts value causing the issue is:

[{mqtt_subscription_opts, 1, false, false, 0, undefined}]

[michaelklishin]

Yeah, that's nowhere near a standard AMQP 0-9-1 table row format.

We'll have to discuss with the team what our options are, if any.

[sergio-aguilar-tuhh]

Okey, thanks so much @michaelklishin.