RabbitMQ 4.3.0

RabbitMQ 4.3.0 is a new feature release.

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, add the following
line to rabbitmq.conf:

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

Classic Queues v1 Storage (CQv1) is Removed

This release removes the original classic queue storage implementation these days
known as CQv1. A 2nd generation implementation called CQv2 has been adopted
as the default starting with 4.2.0.

This means that attempts to declare a queue using the following optional queue arguments will fail:

• x-queue-mode set to any value
• x-queue-version set to 1

Existing classic queues upgraded to CQv2 during an earlier upgrade to 4.2.x will continue
operating as usual.

Consumer Timeouts are No Longer Evaluated for Classic Queues and Streams

This release moves consumer timeout handling responsibility into the queues
themselves. Also, all protocols (except for the stream protocol) now evaluate
consumer timeout for queue types that support them. Classic queues and streams
never evaluate consumer timeouts as their use cases largely avoid the need for
such as feature.

Release Highlights

Khepri is Now The Only Metadata Store

As of this release, Khepri is the only metadata store supported
by RabbitMQ: Mnesia was removed completely.

In practical operational terms, this means that

1. For a cluster to be available, a majority of nodes must be online at all times
2. Failure and partition recovery in a RabbitMQ cluster is now significantly
   simpler and uniform: all components that have replicated state (Khepri, quorum queues, streams)
   recover per Raft recovery semantics

Quorum Queues Enhancements

This release upgrades the Ra dependency to 3.x and introduces
a new (8th) version of the quorum queue state machine with several new features and optimisations:

• Strict priority queues with per-priority message counts, correct
  redelivery ordering, and priority-aware message expiration
• Delayed retry for quorum queues: configurable increasing backoff when
  messages are returned
• Consumer timeout for quorum queues: configurable timeout for
  unacknowledged messages, with protocol-specific handling for AMQP 1.0 and
  MQTT
• Recovery snapshots and snapshot throttling to reduce recovery time
  and improve snapshotting decisions
• Memory optimisations including compact message references, optimised
  tuple storage for delayed keys, and removal of rabbit_fifo_index usage

Upgrading to 4.3.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.2.x. Upgrades from earlier series are not supported:
users must upgrade to the latest available 4.2.x patch release before upgrading to 4.3.0.

New Required Feature Flags

All feature flags introduced in 4.2.0 and earlier are required, including the following:

• rabbitmq_4.2.0
• rabbitmq_4.1.0
• rabbitmq_4.0.0
• khepri_db
• quorum_queue_non_voters
• message_containers_deaths_v2

Enable all required feature flags before upgrading to 4.3.0.

If your RabbitMQ cluster had plugin rabbitmq_amqp1_0 enabled in RabbitMQ 3.13.x (and your cluster still serves AMQP 1.0 client connections in 4.x), your cluster should do at least one rolling update after enabling feature flag rabbitmq_4.0.0 but before upgrading to 4.3.0.

Deprecated Features

In 4.3.0 the deprecation phase of the following features advanced from permitted_by_default to denied_by_default:

• amqp_address_v1
• amqp_filter_set_bug
• global_qos
• queue_master_locator
• transient_nonexcl_queues

And the deprecated feature ram_node_type has been removed.

Mixed Version Cluster Compatibility

RabbitMQ 4.3.0 nodes can run alongside 4.2.x in the same cluster.

Mixed version clusters are a mechanism that allows rolling upgrades and are not meant to be run for extended
periods of time (no more than a few hours).

Recommended Post-upgrade Procedures

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

Core Server

Enhancements

• When a message is rejected by a queue, RabbitMQ now provides the queue name and rejection reason to AMQP 1.0 publishers
  in the Rejected outcome. This is particularly useful when multiple queues are bound to an exchange, as it allows
  publishers to identify which specific queue out of several target queues rejected the message and why
  (e.g., maximum queue length reached or queue unavailable). Previously, publishers had no way to determine which queue
  rejected their message or the reason for rejection.

  The queue name and reason are included in the info field of the Rejected outcome's error field:

  • queue: <queue name>
  • reason: maxlen | unavailable

  GitHub issue: #15075

• Quorum queues now support strict priority queues with per-priority message counts,
  correct redelivery ordering across priorities, and priority-aware message expiration scans.

  GitHub issue: #13885

• Quorum queues now support delayed retry with configurable backoff based on delivery count. When messages
  are returned (via reject, nack, or modify), they can be held in a delayed state before becoming
  available again. The delay is based on delivery count: min(min_delay * delivery_count, max_delay).

  Configuration is available via queue arguments (x-delayed-retry-type, x-delayed-retry-min,
  x-delayed-retry-max) or policy keys (delayed-retry-type, delayed-retry-min,
  delayed-retry-max). The retry type can be set to disabled, all, failed, or returned.

  GitHub issue: #13885

• Quorum queues now support a configurable consumer timeout. When a consumer holds unacknowledged
  messages beyond the timeout, the messages are returned to the queue. For AMQP 1.0 clients,
  timed-out deliveries are released via DISPOSITION(state=released) instead of detaching the link,
  allowing the consumer to recover without re-attaching. MQTT consumers are also supported.

  The timeout can be set via the x-consumer-timeout consumer argument, queue argument, consumer-timeout
  policy key, or the global consumer_timeout setting in rabbitmq.conf.

  GitHub issue: #13885

• A new consumer_disconnected_timeout setting controls how long quorum queues wait before returning
  messages when a consumer's node becomes unreachable due to a network partition. The default is 60 seconds.
  Configurable via consumer_disconnected_timeout in rabbitmq.conf, the consumer-disconnected-timeout
  policy key, or the x-consumer-disconnected-timeout queue argument.

  GitHub issue: #13885

• Quorum queue recovery snapshots reduce recovery time after a member restart by avoiding
  the need to replay all enqueue commands from the log.

  GitHub issue: #13885

• Quorum queue snapshot throttling now uses WAL fill ratio and reclaimable byte tracking
  to make smarter snapshotting decisions, yielding roughly one snapshot per queue per WAL cycle
  instead of excessive snapshots in shallow, fast-flowing queues.

  GitHub issue: #13885

• Quorum queue memory optimisations: message references now use a compact packed integer
  representation ("compact" means up to 59-bit) when possible, halving per-message
  memory overhead in many scenarios. The rabbit_fifo_index module is no longer used by the
  main state machine.

  GitHub issue: [#13885](https://github.co...

RabbitMQ 4.2.6

RabbitMQ 4.2.6 is a maintenance release in the 4.2.x release series.

It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Quorum queues: get_checked_out aux command could return messages in incorrect order

  GitHub issue: #16008

• rabbitmqctl forget_cluster_node now removes all quorum queue and stream members (replicas)
  before proceeding to leave the metadata store cluster.

  This order minimizes the risk of some replicas being left behind on the leaving node.

  GitHub issue: #15729

• The channel limit exceeded error message now correctly identifies the per-user limit
  as the reason

  GitHub issue: #15750

• AMQP 0-9-1: configure permission checks now apply to passive queue and exchange declarations,
  matching the behavior of their regular counterparts

• Khepri: missing keys are now correctly distinguished from errors in certain internal operations,
  avoiding spurious error-level log messages

  GitHub issue: #15942

• Bindings targeting Direct Reply-to pseudo-queues are now rejected instead of
  being silently accepted without any functional effect

  GitHub issue: #15935

Enhancements

• More rabbitmq.conf keys now accept tagged values (e.g., encrypted:...)

  GitHub issue: #15808

• When quorum queue members (replicas) are deleted from a node, either manually
  via rabbitmq-queues shrink or as part of rabbitmqctl forget_cluster_node,
  the members are stopped in parallel

  GitHub issue: #15081

• AMQP 0-9-1: configure permission checks now apply to passive queue and exchange declarations,
  matching the behavior of their regular counterparts

  GitHub issue: #16085

• AMQP 0-9-1: when a connection's credentials are refreshed, the permissions cache is now
  cleared and consumer permissions are re-validated immediately

  GitHub issue: #16092

Management Plugin

Bug Fixes

• effective_policy_definition in HTTP API responses now returns an empty JSON object
  (not an array or empty string) when no policy applies to a queue

  GitHub issue: #16017

• Management UI: OAuth 2 combined with basic_auth could fail to reload provider
  configuration correctly

  GitHub issue: #15858

• Management UI: preference cookie expiry now respects the configured session timeout
  setting rather than using a hardcoded value

  GitHub issue: #15814

• Management UI: users were presented with a 401 error after changing their own password
  via the UI. The session is now refreshed automatically

  GitHub issue: #15730

• The deprecated, unused GET /api/auth endpoint was removed

  It has been out of use since 3.11 but never removed.

  GitHub issue: #16083

• POST /api/users/bulk-delete now respects the protected_users configuration,
  matching the behavior of the single-user DELETE /api/users/:name endpoint

  GitHub issue: #16143

• Quorum queue status and stream tracking endpoints now enforce virtual host
  access checks, consistent with all other vhost-scoped endpoints

  GitHub issue: #16104

Enhancements

• HTTP API displays static connection info (peer address, TLS details, auth mechanism)
  even when stats collection is disabled via rabbitmq.conf

  GitHub issue: #16009

• Super stream creation via HTTP API now verifies configure permission, matching
  the stream protocol code path

  GitHub issue: #16099

• Management API regex filters (?name=...&use_regex=true) now enforce match limits,
  preventing pathological patterns from consuming excessive CPU time

  GitHub issue: #16074

MQTT Plugin

Bug Fixes

• Fixed a timing-sensitive issue around Last Will message delivery and session expiration

  GitHub issue: #15999

Enhancements

• MQTT QoS 0 queue type now reports member information in management API responses

  GitHub issue: #15656

Web MQTT Plugin

Enhancements

• A default max_frame_size is now set on WebSocket connections, bounding decompressed frame sizes.
  The limit starts at mqtt.max_packet_size_unauthenticated and is raised after successful CONNECT

  GitHub issue: #16180

• A login_timeout is now enforced for WebSocket connections, matching the TCP listener behavior

  GitHub issue: #16120

• WebSocket Origin header validation is now available via web_mqtt.allow_origins

  GitHub issue: #16158

Web STOMP Plugin

Enhancements

• A default max_frame_size is now set on WebSocket connections. A smaller pre-authentication
  limit is raised after successful STOMP CONNECT, matching the Web MQTT pattern

  GitHub issue: #16180

• A login_timeout is now enforced for WebSocket connections, matching the TCP listener behavior

  GitHub issue: #16120

• WebSocket Origin header validation is now available via web_stomp.allow_origins

  GitHub issue: #16158

Shovel Plugin

Bug Fixes

• AMQP 1.0 shovels now properly detach links when closing connections, preventing
  spurious error log entries during shutdown

  GitHub issue: #15603

• AMQP 1.0 shovel status no longer includes full connection URIs in API responses
  and CLI output

  GitHub issue: #16108

Shovel Management Plugin

Bug Fixes

• DELETE operations now require the policymaker tag, matching the
  federation plugin counterpart

  GitHub issue: #16051

Federation Management Plugin

Bug Fixes

• Federation link restart operations now require the policymaker tag

  GitHub issue: #16051

OAuth 2 Plugin

Bug Fixes

• The auth cache backend now correctly delegates token expiry timestamps to the wrapped backend,
  ensuring connections are closed when tokens expire

  GitHub issue: #16100

• OAuth 2 management UI: improved provider configuration loading and rendering

  GitHub issue: #15858

LDAP Plugin

Bug Fixes

• DN values are now handled per RFC 4514

  GitHub issue: #16101

Trust Store Plugin

Enhancements

• Refactored certificate identification to avoid (unlikely) conflicts

  GitHub issue: #16116

• Proper CLI commands for trust store certificate management have been introduced

  GitHub issue: #15746

• Rejected certificates are now logged with additional diagnostic details

  GitHub issue: #15889

Consistent Hashing Exchange Plugin

Bug Fixes

• Binding weights above 10,000 are now rejected. Previously, extremely large weights could cause
  excessive memory allocation

  GitHub issue: #16118

Dependency Changes

• khepri was upgraded to 0.17.7
• gen_batch_server was upgraded to 0.9.1

RabbitMQ 4.3.0-rc.1

RabbitMQ 4.3.0-rc.1 is a new feature release candidate.

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 or transient exclusive queues instead.

Classic Queues v1 Storage (CQv1) is Removed

This release removes the original classic queue storage implementation these days
known as CQv1. A 2nd generation implementation called CQv2 has been adopted
as the default starting with 4.2.0.

This means that attempts to declare a queue using the following optional queue arguments will fail:

• x-queue-mode set to any value
• x-queue-version set to 1

Existing classic queues upgraded to CQv2 during an earlier upgrade to 4.2.x will continue
operating as usual.

Consumer Timeouts are No Longer Evaluated for Classic Queues and Streams

This release moves consumer timeout handling responsibility into the queues
themselves. Also, all protocols (except for the stream protocol) now evaluate
consumer timeout for queue types that support them. Classic queues and streams
never evaluate consumer timeouts as their use cases largely avoid the need for
such as feature.

Release Highlights

Khepri is Now The Only Metadata Store

As of this release, Khepri is the only metadata store supported
by RabbitMQ: Mnesia was removed completely.

In practical operational terms, this means that

1. For a cluster to be available, a majority of nodes must be online at all times
2. Failure and partition recovery in a RabbitMQ cluster is now significantly
   simpler and uniform: all components that have replicated state (Khepri, quorum queues, streams)
   recover per Raft recovery semantics

Quorum Queues Enhancements

This release upgrades the Ra dependency to 3.x and introduces
a new (8th) version of the quorum queue state machine with several new features and optimisations:

• Strict priority queues with per-priority message counts, correct
  redelivery ordering, and priority-aware message expiration
• Delayed retry for quorum queues: configurable increasing backoff when
  messages are returned
• Consumer timeout for quorum queues: configurable timeout for
  unacknowledged messages, with protocol-specific handling for AMQP 1.0 and
  MQTT
• Recovery snapshots and snapshot throttling to reduce recovery time
  and improve snapshotting decisions
• Memory optimisations including compact message references, optimised
  tuple storage for delayed keys, and removal of rabbit_fifo_index usage

Upgrading to 4.3.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.2.x. Upgrades from earlier series are not supported:
users must upgrade to the latest available 4.2.x patch release before upgrading to 4.3.0.

New Required Feature Flags

All feature flags introduced in 4.2.0 and earlier are required, including the following:

• rabbitmq_4.2.0
• rabbitmq_4.1.0
• rabbitmq_4.0.0
• khepri_db
• quorum_queue_non_voters
• message_containers_deaths_v2

Enable all required feature flags before upgrading to 4.3.0.

If your RabbitMQ cluster had plugin rabbitmq_amqp1_0 enabled in RabbitMQ 3.13.x (and your cluster still serves AMQP 1.0 client connections in 4.x), your cluster should do at least one rolling update after enabling feature flag rabbitmq_4.0.0 but before upgrading to 4.3.0.

Deprecated Features

In 4.3.0 the deprecation phase of the following features advanced from permitted_by_default to denied_by_default:

• amqp_address_v1
• amqp_filter_set_bug
• global_qos
• queue_master_locator
• transient_nonexcl_queues

And the deprecated feature ram_node_type has been removed.

Mixed Version Cluster Compatibility

RabbitMQ 4.3.0 nodes can run alongside 4.2.x in the same cluster.

Mixed version clusters are a mechanism that allows rolling upgrades and are not meant to be run for extended
periods of time (no more than a few hours).

Recommended Post-upgrade Procedures

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

Core Server

Enhancements

• When a message is rejected by a queue, RabbitMQ now provides the queue name and rejection reason to AMQP 1.0 publishers
  in the Rejected outcome. This is particularly useful when multiple queues are bound to an exchange, as it allows
  publishers to identify which specific queue out of several target queues rejected the message and why
  (e.g., maximum queue length reached or queue unavailable). Previously, publishers had no way to determine which queue
  rejected their message or the reason for rejection.

  The queue name and reason are included in the info field of the Rejected outcome's error field:

  • queue: <queue name>
  • reason: maxlen | unavailable

  GitHub issue: #15075

• Quorum queues now support strict priority queues with per-priority message counts,
  correct redelivery ordering across priorities, and priority-aware message expiration scans.

  GitHub issue: #13885

• Quorum queues now support delayed retry with configurable backoff based on delivery count. When messages
  are returned (via reject, nack, or modify), they can be held in a delayed state before becoming
  available again. The delay is based on delivery count: min(min_delay * delivery_count, max_delay).

  Configuration is available via queue arguments (x-delayed-retry-type, x-delayed-retry-min,
  x-delayed-retry-max) or policy keys (delayed-retry-type, delayed-retry-min,
  delayed-retry-max). The retry type can be set to disabled, all, failed, or returned.

  GitHub issue: #13885

• Quorum queues now support a configurable consumer timeout. When a consumer holds unacknowledged
  messages beyond the timeout, the messages are returned to the queue. For AMQP 1.0 clients,
  timed-out deliveries are released via DISPOSITION(state=released) instead of detaching the link,
  allowing the consumer to recover without re-attaching. MQTT consumers are also supported.

  The timeout can be set via the x-consumer-timeout consumer argument, queue argument, consumer-timeout
  policy key, or the global consumer_timeout setting in rabbitmq.conf.

  GitHub issue: #13885

• A new consumer_disconnected_timeout setting controls how long quorum queues wait before returning
  messages when a consumer's node becomes unreachable due to a network partition. The default is 60 seconds.
  Configurable via consumer_disconnected_timeout in rabbitmq.conf, the consumer-disconnected-timeout
  policy key, or the x-consumer-disconnected-timeout queue argument.

  GitHub issue: #13885

• Quorum queue recovery snapshots reduce recovery time after a member restart by avoiding
  the need to replay all enqueue commands from the log.

  GitHub issue: #13885

• Quorum queue snapshot throttling now uses WAL fill ratio and reclaimable byte tracking
  to make smarter snapshotting decisions, yielding roughly one snapshot per queue per WAL cycle
  instead of excessive snapshots in shallow, fast-flowing queues.

  GitHub issue: #13885

• Quorum queue memory optimisations: message references now use a compact packed integer
  representation ("compact" means up to 59-bit) when possible, halving per-message
  memory overhead in many scenarios. The rabbit_fifo_index module is no longer used by the
  main state machine.

  GitHub issue: #13885

• Quorum queues now allow unlimited explicit message returns. The delivery limit is based on
  delivery-count rather than acquired-count, so messages can be explicitly returned to the
  queue without counting towards the delivery limit.

  GitHub issue: #13885

• The `x-mod...

RabbitMQ 4.3.0-rc.0

RabbitMQ 4.3.0-rc.0 is a preview of a new feature release.

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

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

Classic Queues v1 Storage (CQv1) is Removed

This release removes the original classic queue storage implementation these days
known as CQv1. A 2nd generation implementation called CQv2 has been adopted
as the default starting with 4.2.0.

This means that attempts to declare a queue using the following optional queue arguments will fail:

• x-queue-mode set to any value
• x-queue-version set to 1

Existing classic queues upgraded to CQv2 during an earlier upgrade to 4.2.x will continue
operating as usual.

Consumer Timeouts are No Longer Evaluated for Classic Queues and Streams

This release moves consumer timeout handling responsibility into the queues
themselves. Also, all protocols (except the stream protocol) now evaluate
consumer timeout for queue types that support them. Classic queues and streams
never evaluate consumer timeouts as their use cases cause less demand for it.

Release Highlights

Khepri is Now The Only Metadata Store

As of this release, Khepri is the only metadata store supported
by RabbitMQ: Mnesia was removed completely.

In practical operational terms, this means that

1. For a cluster to be available, a majority of nodes must be online at all times
2. Failure and partition recovery in a RabbitMQ cluster is now significantly
   simpler and uniform: all components that have replicated state (Khepri, quorum queues, streams)
   recover per Raft recovery semantics

Quorum Queues Enhancements

This release upgrades the Ra dependency to 3.x and introduces
a new (8th) version of the quorum queue state machine with several new features and optimisations:

• Strict priority queues with per-priority message counts, correct
  redelivery ordering, and priority-aware message expiration
• Delayed retry for quorum queues: configurable increasing backoff when
  messages are returned
• Consumer timeout for quorum queues: configurable timeout for
  unacknowledged messages, with protocol-specific handling for AMQP 1.0 and
  MQTT
• Recovery snapshots and snapshot throttling to reduce recovery time
  and improve snapshotting decisions
• Memory optimisations including compact message references, optimised
  tuple storage for delayed keys, and removal of rabbit_fifo_index usage

Upgrading to 4.3.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.2.x. Upgrades from earlier series are not supported:
users must upgrade to the latest available 4.2.x patch release before upgrading to 4.3.0.

New Required Feature Flags

All feature flags introduced in 4.2.0 and earlier are required, including the following:

• rabbitmq_4.2.0
• rabbitmq_4.1.0
• rabbitmq_4.0.0
• khepri_db
• quorum_queue_non_voters
• message_containers_deaths_v2

Enable all required feature flags before upgrading to 4.3.0.

If your RabbitMQ cluster had plugin rabbitmq_amqp1_0 enabled in RabbitMQ 3.13.x (and your cluster still serves AMQP 1.0 client connections in 4.x), your cluster should do at least one rolling update after enabling feature flag rabbitmq_4.0.0 but before upgrading to 4.3.0.

Deprecated Features

In 4.3.0 the deprecation phase of the following features advanced from permitted_by_default to denied_by_default:

• amqp_address_v1
• amqp_filter_set_bug
• global_qos
• queue_master_locator
• transient_nonexcl_queues

And the deprecated feature ram_node_type has been removed.

Mixed version cluster compatibility

RabbitMQ 4.3.0 nodes can run alongside 4.2.x in the same cluster.

Mixed version clusters are a mechanism that allows rolling upgrades and are not meant to be run for extended
periods of time (no more than a few hours).

Recommended Post-upgrade Procedures

This version does not require any additional post-upgrade procedures
compared to other versions.

Changes Worth Mentioning

Core Server

Enhancements

• When a message is rejected by a queue, RabbitMQ now provides the queue name and rejection reason to AMQP 1.0 publishers
  in the Rejected outcome. This is particularly useful when multiple queues are bound to an exchange, as it allows
  publishers to identify which specific queue out of several target queues rejected the message and why
  (e.g., maximum queue length reached or queue unavailable). Previously, publishers had no way to determine which queue
  rejected their message or the reason for rejection.

  The queue name and reason are included in the info field of the Rejected outcome's error field:

  • queue: <queue name>
  • reason: maxlen | unavailable

  GitHub issue: #15075

• Quorum queues now support strict priority queues with per-priority message counts,
  correct redelivery ordering across priorities, and priority-aware message expiration scans.

  GitHub issue: #13885

• Quorum queues now support delayed retry with configurable backoff based on delivery count. When messages
  are returned (via reject, nack, or modify), they can be held in a delayed state before becoming
  available again. The delay is based on delivery count: min(min_delay * delivery_count, max_delay).

  Configuration is available via queue arguments (x-delayed-retry-type, x-delayed-retry-min,
  x-delayed-retry-max) or policy keys (delayed-retry-type, delayed-retry-min,
  delayed-retry-max). The retry type can be set to disabled, all, failed, or returned.

  GitHub issue: #13885

• Quorum queues now support a configurable consumer timeout. When a consumer holds unacknowledged
  messages beyond the timeout, the messages are returned to the queue. For AMQP 1.0 clients,
  timed-out deliveries are released via DISPOSITION(state=released) instead of detaching the link,
  allowing the consumer to recover without re-attaching. MQTT consumers are also supported.

  The timeout can be set via the x-consumer-timeout consumer argument, queue argument, consumer-timeout
  policy key, or the global consumer_timeout setting in rabbitmq.conf.

  GitHub issue: #13885

• A new consumer_disconnected_timeout setting controls how long quorum queues wait before returning
  messages when a consumer's node becomes unreachable due to a network partition. The default is 60 seconds.
  Configurable via consumer_disconnected_timeout in rabbitmq.conf, the consumer-disconnected-timeout
  policy key, or the x-consumer-disconnected-timeout queue argument.

  GitHub issue: #13885

• Quorum queue recovery snapshots reduce recovery time after a member restart by avoiding
  the need to replay all enqueue commands from the log.

  GitHub issue: #13885

• Quorum queue snapshot throttling now uses WAL fill ratio and reclaimable byte tracking
  to make smarter snapshotting decisions, yielding roughly one snapshot per queue per WAL cycle
  instead of excessive snapshots in shallow, fast-flowing queues.

  GitHub issue: #13885

• Quorum queue memory optimisations: message references now use a compact packed integer
  representation ("compact" means up to 59-bit) when possible, halving per-message
  memory overhead in many scenarios. The rabbit_fifo_index module is no longer used by the
  main state machine.

  GitHub issue: #13885

• Quorum queues now allow unlimited explicit message returns. The delivery limit is based on
  delivery-count rather than acquired-count, so messages can be explicitly returned to the
  queue without counting towards the delivery limit.

  GitHub issue: #13885

• When quorum queue members (replicas) are deleted from a node, either manually
  via rabbitmq-queues shrink or as part of rabbitmqctl forget_cluster_node,
  the members are stopped in parallel.

  GitHub issue: #15081

• Purging a quorum queue now also removes at-least-once dead-lettered messages that were pending delivery.

  GitHub issue: #13885

Bug Fi...

RabbitMQ 4.2.5

RabbitMQ 4.2.5 is a maintenance release in the 4.2.x release series.

It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Classic queues could terminate and restart during recovery in certain rare conditions.

  GitHub issue: #15595

• Quorum queues could incorrectly reject messages during deletion.

  GitHub issue: #15554

• Peer discovery could run into a crash when rabbit_nodes:list_members/0 returned
  an empty list due to an error or a timeout.

  GitHub issue: #15568

• Definition import now strips a leading UTF-8 BOM if the input file has one.

  GitHub issues: #13748, #15550

• Exceptions thrown by decorator callbacks (such as those used by federation)
  during policy change notifications were silently suppressed. They are now logged.

  GitHub issue: #15525

Enhancements

• Improved Mnesia-to-Khepri migration throughput.

  GitHub issue: #15480

• Additional aten settings are now exposed in rabbitmq.conf.
  Previously only the poll interval was configurable.

  GitHub issue: #15564

Stream Plugin

Bug Fixes

• parse_command/1 crashed with a function_clause error when receiving a zero-size frame,
  such as those sent by load balancer probes or port scanners.

  GitHub issue: #15703

• rabbit_stream_manager could crash with a case_clause error when a stream declaration
  failed due to a metadata store timeout.

  GitHub issue: #15699

Enhancements

• Less log noise from load balancer and port scanner probes (that do not perform an AMQP 1.0 or AMQP 0-9-1 handshake)

  GitHub issue: #15715

Management Plugin

Bug Fixes

• Request bodies above the configured maximum limit are now rejected earlier.

  GitHub issue: #15712

• Validation improvements for several API endpoints.

  They now ignore node names that do not refer to existing cluster members,
  reject unknown fields, etc.

  GitHub issues: #15622, #15623, #15625, #15627

• Queue API responses now include policy-related fields (policy, operator_policy,
  effective_policy_definition) and delivery_limit when management stats collection
  is disabled via rabbitmq.conf.

  GitHub issues: #15182, #15651

CLI Tools

Bug Fixes

• rabbitmq-diagnostics status and rabbitmqctl status crashed when targeting a node
  in maintenance mode because vm_memory_high_watermark was nil
  (the vm_memory_monitor process does not run in that state).

  GitHub issues: #15678, #15680

Enhancements

• rabbitmq-plugins now produces a clearer error message when run by a non-root user.

  GitHub issue: #15701

Federation Management Plugin

Bug Fixes

• The x-internal-purpose and consumer_timeout argument values are now correctly escaped.

  GitHub issues: #15606, #15708

Prometheus Plugin

Bug Fixes

• Per-object metrics endpoint (/metrics/per-object) no longer emits duplicate HELP
  and TYPE metadata lines for Raft metrics when both quorum queues and Khepri are in use,
  which caused scraper parser errors.

  GitHub issues: #15600, #15610

Grafana Dashboards

Enhancements

• The Overview dashboard's "TCP sockets available" panel was replaced with a "File descriptors available" panel
  that uses two modern metrics, rabbitmq_process_max_fds and rabbitmq_process_open_fds.

  GitHub issues: #12673, #15618

Shovel Plugin

Bug Fixes

• An attempt to declare a dynamic shovel with multiple src-queue-args or dest-queue-args values
  configured could run into an exception during validation.

  GitHub issues: #8323, #8356

Web STOMP Plugin

Bug Fixes

• A terminated heartbeat monitor process could cause a crash during connection shutdown.

  GitHub issue: #15607

Dependency Changes

None in this release.

RabbitMQ 4.2.4

RabbitMQ 4.2.4 is a maintenance release in the 4.2.x release series.

It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Classic queue message store could run into an exception when a file was concurrently deleted by a compaction operation.

  GitHub issue: #15411

• rabbit_quorum_queue:stat/2 could fail when the quorum queue leader was undefined.

  GitHub issues: #15400, #15423

• The amq.rabbitmq.log exchange is now declared unconditionally at node boot,
  avoiding a potential deadlock between feature flag enablement and logging to the exchange sink.

  GitHub issue: #15320

MQTT Plugin

Bug Fixes

• Variable interpolation in topic permissions now.
  escapes the special regular expression characters before interpolation.

  GitHub issue: #15442

Stream Plugin

Bug Fixes

• Single Active Consumer coordinator
  could deadlock when a consumer being deactivated would lose its connection, leaving the consumer group
  without an active consumer.

  GitHub issue: #15353

Management Plugin

Bug Fixes

• The Policies page in the management UI incorrectly displayed quorum queue arguments
  twice on the declaration form in place of stream queue arguments.

  GitHub issue: #15335

• The clustering listener now correctly reports its TLS enablement status.

  GitHub issue: #15399

Enhancements

• GET /api/overview and GET /api/nodes now report crypto library (such as OpenSSL) version.

  GitHub issue: #15468

• RabbitMQ and Erlang/OTP versions are now included in GET /api/nodes responses.

  GitHub issue: #15454

• Login page usability improvements: autofocus on the username field and autocomplete attributes
  for browser password manager integration.

  GitHub issue: #15398

CLI Tools

Enhancements

• rabbitmq-upgrade has_reached_target_cluster_size is a new command that checks whether
  the cluster has reached its target size, as provided in rabbitmq.conf.

  This is useful for automating rolling upgrades, particularly on Kubernetes.

  GitHub issue: #15404

Shovel Plugin

Bug Fixes

• Stopping and deleting a shovel could fail with a badmatch exception
  when the underlying worker process no longer existed.

  GitHub issue: #15408

Trust Store Plugin

Enhancements

• HTTPS endpoint requests now have a configurable timeout (20 seconds by default),
  preventing the plugin from hanging indefinitely when a provider fails to respond.

  GitHub issues: #15308, #15310

AWS Peer Discovery Plugin

Bug Fixes

• Nodes on EC2 instances in non-running states (stopping, stopped, shutting-down, terminated)
  are now filtered out from peer discovery results.

  GitHub issue: #15388

Enhancements

• Multiple hostname resolution paths can now be configured. This is an upgrade pathway
  for scenarios where resolution hostnames have to change.

  GitHub issue: #14705

Tracing Plugin

Bug Fixes

• The plugin now uses UTF-8 encoding for traced messages.

  GitHub issue: #15439

Dependency Changes

• ra was upgraded to 2.17.2

RabbitMQ 4.2.3

RabbitMQ 4.2.3 is a maintenance release in the 4.2.x release series.

It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Default queue type handling is now more defensive, avoiding an issue where
  attempts to declare a queue in a virtual host without any DQT set would result
  in a PRECONDITION_FAILED exception instead of falling back to the classic queue type
  for DQT.

  GitHub issues: #11541, #12109, #12821, #13837

• Classic queue recovery on Windows could fail due to an OS-specific file locking behavior.
  Such failures are now retried in two more contexts.

  GitHub issue: #15136

• Certain exchange update operations in Khepri could cause severe contention.

  GitHub issue: #15236

• Topic exchange binding deletions could leave orphaned trie edges in the Khepri projection,
  potentially causing a slowly creeping memory leak.

  GitHub issue: #15025

• When a client that owns an exclusive queue disconnects and immediately reconnects and redeclares the same queue
  (under the same name), RabbitMQ node could delete the new queue depending on the timing of events.

  Previously the only workaround was to use exclusive server-named queues for clients that exhibited
  this behavior. Now RabbitMQ nodes take internal owner identity into account and will remove
  the original queue but not the new one.

  GitHub issue: #15276

• "Other ETS" and "Other system" memory metrics could end up being reported as negative values
  due to concurrent ETS table updates, deletion and creation on the node.

  GitHub issue: #15289

• mirrored_supervisor:child/2 could fail with a badmatch exception
  when a significant enough number of shovels (or federation links) was removed.

  GitHub issue: #15229

• Quorum queue could run into a logging exception during node drain.

  GitHub issue: #15212

Enhancements

• Topic binding deletion in Khepri is now significantly more efficient.

  Deleting 100k topic bindings could previously take up to 30 minutes and now takes
  some 3-4 seconds.

  GitHub issue: #15214

• It is now possible to rabbitmq-queues shrink only a subset of quorum queues on
  a node using a pattern (a regex).

  GitHub issue: #15021

• CRL (Certificate Revocation List) cache can now be configured via rabbitmq.conf.

  GitHub issues: #2338, #15160

Federation Plugins

Bug Fixes

• Restored exchange federation compatibility in mixed 4.2.x/4.1.x multi-node clusters.

  GitHub issue: #15252

Enhancements

• Federation links and their connections are now stopped in parallel.

  This significantly improves shutdown time for nodes with many (into thousands) federation links.

  GitHub issue: #15271

• Federation links no longer restart during plugin or node shutdown.

  For nodes with hundreds or thousands of federation links, link recovery could
  significantly delay node shutdown.

  GitHub issue: #15258

• Federation links use AMQP 0-9-1 connections to remote nodes (clusters).

  Previously the timeout used when those connections are closed was fixed to 10 seconds.
  Now it is configurable via rabbitmq.conf in milliseconds:

  # 3 seconds for exchange federation
  federation.exchanges.connection_close_timeout = 3000
  
  # 3 seconds for queue federation
  federation.queues.connection_close_timeout = 3000

  The maximum supported value is 5 seconds (5000 ms).

  GitHub issue: #15268

CLI Tools

Enhancements

• rabbitmq-streams grow and rabbitmq-streams shrink are new commands that mirror existing
  rabbitmq-queues grow and rabbitmq-queues shrink functionality for streams.

  GitHub issue: #15189

MQTT Plugin

Enhancements

• A new configuration option, mqtt.disconnect_on_unauthorized, controls whether
  MQTT connections are closed upon authorization failures (for example, an attempt to
  consume from a topic the client has no permission for).

  When set to false, the connection remains open and an appropriate protocol-level
  response is sent to the client instead.

  The default value is true, same as RabbitMQ MQTT implementation's historic behavior.

  GitHub issue: #15201

Management Plugin

Bug Fixes

• OAuth 2: preferred_auth_mechanism and strict_auth_mechanism are no longer validated
  when not used (configured).

  GitHub issue: #15148

etcd Peer Discovery Plugin

Bug Fixes

• When credentials were provided, the password was double-encrypted, resulting in
  etcd authentication failures.

  GitHub issue: #15191

HTTP Auth Backend Plugin

Bug Fixes

• The customize_hostname_check TLS option was unintentionally ignored.

  GitHub issue: #15184

Dependency Changes

• khepri was upgraded to 0.17.4
• khepri_mnesia_migration was upgraded to 0.8.1
• osiris was upgraded to 1.10.3

RabbitMQ 4.1.8

RabbitMQ 4.1.8 is a maintenance release in the 4.1.x release series.

It is strongly recommended that you read 4.1.0 release notes
in detail if upgrading from a version prior to 4.1.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Classic queue recovery on Windows could fail due to an OS-specific file locking behavior.
  Such failures are now retried in two more contexts.

  GitHub issue: #15136

• Default queue type handling is now more defensive, avoiding an issue where
  attempts to declare a queue in a virtual host without any DQT set would result
  in a PRECONDITION_FAILED exception instead of falling back to the classic queue type
  for DQT.

GitHub issues: #11541, #12109, #12821, #13837

• Topic exchange binding deletions could leave orphaned trie edges in the Khepri projection,
  potentially causing a slowly creeping memory leak.

  GitHub issue: #15025

• When a client that owns an exclusive queue disconnects and immediately reconnects and redeclares the same queue
  (under the same name), RabbitMQ node could delete the new queue depending on the timing of events.

  Previously the only workaround was to use exclusive server-named queues for clients that exhibited
  this behavior. Now RabbitMQ nodes take internal owner identity into account and will remove
  the original queue but not the new one.

  GitHub issue: #15276

• "Other ETS" and "Other system" memory metrics could end up being reported as negative values
  due to concurrent ETS table updates, deletion and creation on the node.

  GitHub issue: #15289

• mirrored_supervisor:child/2 could fail with a badmatch exception
  when a significant enough number of shovels (or federation links) was removed.

  GitHub issue: #15229

Federation Plugins

Bug Fixes

• Restored exchange federation compatibility in mixed 4.2.x/4.1.x multi-node clusters.

  GitHub issue: #15252

Enhancements

• Federation links and their connections are now stopped in parallel.

  This significantly improves shutdown time for nodes with many (into thousands) federation links.

  GitHub issue: #15271

• Federation links no longer restart during plugin or node shutdown.

  For nodes with hundreds or thousands of federation links, link recovery could
  significantly delay node shutdown.

  GitHub issue: #15258

• Federation links use AMQP 0-9-1 connections to remote nodes (clusters).

  Previously the timeout used when those connections are closed was fixed to 10 seconds.
  Now it is configurable via rabbitmq.conf in milliseconds:

  # 3 seconds for exchange federation
  federation.exchanges.connection_close_timeout = 3000
  
  # 3 seconds for queue federation
  federation.queues.connection_close_timeout = 3000

  The maximum supported value is 5 seconds (5000 ms).

  GitHub issue: #15268

MQTT Plugin

Enhancements

• A new configuration option, mqtt.disconnect_on_unauthorized, controls whether
  MQTT connections are closed upon authorization failures (for example, an attempt to
  consume from a topic the client has no permission for).

  When set to false, the connection remains open and an appropriate protocol-level
  response is sent to the client instead.

  The default value is true, same as RabbitMQ MQTT implementation's historic behavior.

  GitHub issue: #15201

RabbitMQ 4.2.2

RabbitMQ 4.2.2 is a maintenance release in the 4.2.x release series.

It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Bug Fixes

• Fixes a binding deletion-related memory leak in Khepri.

  This leak primarily affected systems with high binding churn.

  GitHub issue: #15024

• Corrected a performance regression around metric collection that could have a meaningful impact on quorum queues.

  GitHub issue: rabbitmq/seshat#16

• AMQP 1.0 link error frames did not have settlement set in certain failure scenarios,
  namely when attaching a link failed due to a missing source (queue or stream).

  GitHub issue: #15004

• AMQP 1.0 clients that publish messages without a body now get a clearer error message.
  Messages without a body explicitly violate the AMQP 1.0 specification.

  GitHub issue: #15048

• Default operator policy pre-configuration in rabbitmq.conf were unintentionally missing a key,
  default_policies.operator.$id.apply_to, for controlling what objects the policy applies to.

  GitHub issue: #14988

• Definition import is now more defensive when importing exchanges.

  GitHub issue: #15128

Enhancements

• More efficient Khepri (metadata store) querying.

  GitHub issue: rabbitmq/khepri#349

• Removed a cool down delay between stream chunk redelivery attempts.

  GitHub issue: #14766

• Stream data directory can now be configured via rabbitmq.conf.

  GitHub issue: #15014

• Stream replication: IP address family (IPv4 or IPv6) can now be configured via rabbitmq.conf.

  GitHub issue: #15012

OAuth 2 Plugin

Bug Fixes

• When multiple resource server IDs are configured, management UI login screen now provides a way to pre-select a specific resource ID
  before logging in.

  As part of this change, when multiple resource server IDs are configured, their order stored internally now reflects
  that in rabbitmq.conf.

  GitHub issue: #15044

Management Plugin

Bug Fixes

• GET /api/deprecated-features/used no longer returns an empty state field.

  GitHub issue: #14340

• Feature flag icons now contrast well when the dark mode is used in the UI.

  GitHub issue: #14620

• Corrected an invalid apply_to value (classic_queue instead of classic_queues)
  on the policy declaration form.

  Declaring a policy "directly" via the HTTP API was not affected.

  GitHub issue: #15054

Enhancements

• Queue declaration form fields were reordered so that the queue type dropdown comes before
  the virtual host.

  GitHub issue: #15017

• The order of configured OAuth 2 resource servers is now preserved in the management UI.
  Additionally, a resource server ID can now be pre-selected during service-provider-initiated logons.

  GitHub issue: #15044

Prometheus Plugin

Enhancements

• GET /metrics/per-object responses on systems with thousands of objections now takes 20-30% less time.

  GitHub issue: #15035

• Prometheus scraping endpoint responses are now streamed instead of being fully buffered before transmission.
  This reduces memory peak footprint and improves response times for nodes with a larger number of objects.

  GitHub issue: #15018

Bug Fixes

• Fixed a dependency loading issue with ddskerl (a Prometheus library dependency)
  that could cause stop_app to fail.

  GitHub issue: #15027

CLI Tools

Bug Fixes

• rabbitmq-queues quorum_status could run into an exception when a quorum queue member dies before recording any metrics.

  GitHub issue: #15003

Web MQTT Plugin

Bug Fixes

• The plugin now supports the mqttv3.1 WebSocket subprotocol in addition to mqtt,
  improving compatibility with older MQTT clients.

  GitHub issue: #15009

AWS Peer Discovery Plugin

Bug Fixes

• The plugin now uses IPv6 discovery endpoints in IPv6-only environments.

  GitHub issue: #14974

Tracing Plugin

Bug Fixes

• Trace files served via the management UI now include proper UTF-8 charset specification.

  GitHub issue: #14970

Trust Store Plugin

Bug Fixes

• The plugin now merges user-provided TLS options with the options it needs in a safer manner.

  GitHub issue: #15116

Dependency Changes

• khepri was upgraded to 0.17.3
• seshat was upgraded to 1.0.1

RabbitMQ 4.1.7

RabbitMQ 4.1.7 is a maintenance release in the 4.1.x release series.

It is strongly recommended that you read 4.1.0 release notes
in detail if upgrading from a version prior to 4.1.0.

Minimum Supported Erlang Version

RabbitMQ and Erlang/OTP Compatibility Matrix has more details on Erlang version requirements for RabbitMQ.

Nodes will fail to start on older Erlang releases.

Changes Worth Mentioning

Release notes can be found on GitHub at rabbitmq-server/release-notes.

Core Server

Enhancements

• Stream replication: IP address family (IPv4 or IPv6) can now be configured via rabbitmq.conf.

  GitHub issue: #15013

Management Plugin

Bug Fixes

• GET /api/deprecated-features/used no longer returns an empty state field.

  GitHub issue: #15059

• Feature flag icons now contrast well when the dark mode is used in the UI.

  GitHub issue: #15070

Web MQTT Plugin

Bug Fixes

• The plugin now supports the mqttv3.1 WebSocket subprotocol in addition to mqtt,
  improving compatibility with older MQTT clients.

  GitHub issue: #15010

AWS Peer Discovery Plugin

Bug Fixes

• The plugin now uses IPv6 discovery endpoints in IPv6-only environments.

  GitHub issue: #14987

Tracing Plugin

Bug Fixes

• Trace files served via the management UI now include proper UTF-8 charset specification.

  GitHub issue: #14972