rabbitmq-server

Breaking changes

What to check before upgrading, taken from the notes of the last 30 releases.

• v4.4.0Oct 19, 2026

  Breaking Changes and Compatibility Notes

  • The following AMQP 0-9-1 headers are no longer parsed:

     x-amqp-1.0-properties
     x-amqp-1.0-app-properties
     x-amqp-1.0-message-annotations
     x-amqp-1.0-footer
  

  RabbitMQ 3.13 and earlier used them to carry the AMQP 1.0 sections of a

  message received over AMQP 1.0. Nothing has written them since 4.0, so only

  a message stored by a 3.13 or earlier node and not read since carries them.

  Such a message is still delivered, with these headers converted like any

  other x- header rather than restored as AMQP 1.0 sections.

  • Likewise, the x-basic-delivery-mode, x-basic-priority and

  x-basic-expiration message annotations are no longer parsed. They were

  written before 4.0 when an AMQP 0-9-1 message was encoded as AMQP 1.0 for a

  stream, so only a stream entry written by a 3.13 or earlier node carries

  them, and reading it no longer restores those three properties.

  • OpenID Connect discovery responses are now validated more strictly. A

  deployment whose identity provider serves non-HTTPS (http://) endpoints,

  or whose issuer claim does not match the discovery endpoint used to

  retrieve it, will fail discovery validation after the upgrade.

  This is known to affect Cloud Foundry UAA, whose issuer is its token endpoint URL

  rather than a prefix of its discovery endpoint.

  Set auth_oauth2.discovery.verify_issuer and/or

  auth_oauth2.discovery.verify_https_endpoints to false before upgrading

• v4.3.0Apr 23, 2026

  Breaking Changes and Compatibility Notes

  Mnesia and Parition Handling Strategies are Removed

  Since only 4.2.x clusters can upgrade to 4.3.0 in place, this

  won't be a breaking change for nearly all instalations but it will affect community

  plugins that use Mnesia.

  All partition handling-related keys in rabbitmq.conf will be

  accepted by 4.3.0 nodes but won't have any effect:

  • cluster_partition_handling
  • cluster_partition_handling.pause_if_all_down.recover
  • cluster_partition_handling.pause_if_all_down.nodes.$name

  Team RabbitMQ recommends removing the above keys from rabbitmq.conf before or shortly after upgrading.

  Deprecated Features are Now Disabled by Default

  A number of deprecated features are now disabled

  by default and require the user to opt-in in order to use them.

  This includes non-durable (transient) non-exclusive queues:

  attempts to declare a queue with such property combination will be rejected by default.

  Use durable queues, transient exclusive queues, or durable queues with a queue TTL instead.

  To explicitly allow transient non-exclusive queues, make sure that

  all nodes in the cluster include the following rabbitmq.conf key

  and were restarted so that all nodes have a consistent view of the deprecated

  feature settings:

  #### Enables deprecated non-durable (transient) non-exclusive queues
  #### (disabled by default as of RabbitMQ 4.3.0, will be removed in a later version).
  #
  

• v4.2.0Oct 27, 2025

  Breaking Changes and Compatibility Notes

  Default value for AMQP 1.0 durable field.

  Starting with RabbitMQ 4.2, if a sending client omits the header section, RabbitMQ assumes the durable field to be false complying with the AMQP 1.0 spec:

  AMQP 1.0 apps or client libraries must set the durable field of the header section to true to mark the message as durable.

  Team RabbitMQ recommends client libraries to send messages as durable by default.

  All AMQP 1.0 client libraries maintained by Team RabbitMQ send messages as durable by default.

  Mandatory flag in Direct Reply-To

  Starting with RabbitMQ 4.2, if an AMQP 0.9.1 Direct Reply-To responder (RPC server) publishes with the mandatory flag set, then amq.rabbitmq.reply-to.* is treated as a queue.

  Whether the requester (RPC client) is still there to consume the reply is not checked at routing time.

  In other words, if the responder publishes to only this queue name, then the message will be considered "routed" and RabbitMQ will therefore not send a basic.return.

  Very Rarely Used .cacerts Settings are Removed from rabbitmq.conf

  *.cacerts (not to be confused with cacertfile) settings in rabbitmq.conf did not have the expected effect and were removed

  to eliminate confusion.

  Upgrading to 4.2.0

  Documentation guides on upgrades

  See the Upgrading guide for documentation on upgrades and GitHub releases

  for release notes of individual releases.

  This release series supports upgrades from 4.1.x, 4.0.x and 3.13.x.

  If upgrading from a 3.13.x cluster that uses classic mirrored queues,

  take a look at what modern CLI tools can offer for such migrations away from classic mirrored queues

  via Blue/Green deployments.

  Blue/Green Deployment-style upgrades are available for migrations

  from RabbitMQ 3.12.x series.