RabbitMQ Knowledge Patch
Use this skill when upgrading or operating RabbitMQ, changing broker or plugin
configuration, integrating a protocol client, or updating monitoring and
automation. Determine the deployed RabbitMQ and Erlang/OTP versions first, then
open the reference that matches the task.
Reference index
| Reference |
Topics |
| migrations-and-deprecations.md |
Upgrade paths, rolling upgrades, Khepri migration, removed settings and deprecated features |
| clustering-configuration-and-operations.md |
Cluster formation, feature flags, resource alarms, health checks, limits, diagnostics, Erlang compatibility |
| queues-streams-and-exchanges.md |
Queue semantics, quorum queues, streams, exchange limits and routing behavior |
| protocols-and-clients.md |
AMQP 1.0, AMQP 0-9-1, MQTT, STOMP, WebSocket, Direct Reply-To, client behavior |
| security-and-authentication.md |
OAuth/OIDC, LDAP, TLS, authentication backends, authorization, credential refresh |
| management-api-and-observability.md |
HTTP API, management UI, Prometheus metrics, logging, definition import/export |
| federation-shovels-and-extensions.md |
Federation, Shovels, plugin APIs, peer discovery, Tanzu features |
Upgrade decision points
Moving to 4.3
- Upgrade through 4.2.x; 4.3.x accepts upgrades only from 4.2.x.
- Enable all stable feature flags before the upgrade.
- Khepri is mandatory. Enable
khepri_db before the first 4.3 node starts, or
that node migrates Mnesia metadata during boot.
- If the cluster used AMQP 1.0 on 3.13 with
rabbitmq_amqp1_0 enabled, complete
a rolling update after enabling rabbitmq_4.0.0 and before entering 4.3.
- Keep a 4.3/4.2 mixed cluster only for the few hours required by a rolling
upgrade.
- Run 4.3.x on Erlang/OTP 27.0 or later; older runtimes do not start.
Moving to 4.2 or 4.1
- 4.2 accepts direct upgrades from 4.1.x, 4.0.x, or 3.13.x. Existing Mnesia
deployments remain on Mnesia until Khepri is explicitly enabled.
- 4.1 accepts 4.0.x or 3.13.x after all stable feature flags are enabled.
- A 3.13 cluster already using Khepri cannot upgrade in place to 4.x because
the metadata format is incompatible; use a blue-green migration.
- Mixed-version clusters exist only for rolling upgrades. Do not enable
release-specific features until every node has reached the new series.
- Do not use grow-then-shrink as a whole-cluster upgrade strategy; it changes
replica identities and can cause large data transfers.
Breaking removals and defaults
Metadata and partition handling
- 4.3 supports Khepri only. Remove Mnesia-era partition settings:
pause_if_all_down, pause_minority, and autoheal.
- The accepted keys
cluster_partition_handling,
cluster_partition_handling.pause_if_all_down.recover, and
cluster_partition_handling.pause_if_all_down.nodes.$name are inert.
rabbitmqctl force_reset is deprecated because it is incompatible with
Khepri.
Queues and deprecated features
- Classic queue v1 storage is gone. Declarations fail if
x-queue-mode has
any value or x-queue-version is 1; convert queues to CQv2 on 4.2 first.
- Non-durable, non-exclusive classic queues are rejected by default. Prefer a
durable queue, an exclusive transient queue, or a durable queue with TTL.
Temporary compatibility requires
deprecated_features.permit.transient_nonexcl_queues = true.
amqp_address_v1, amqp_filter_set_bug, global_qos, and
queue_master_locator are denied unless explicitly permitted.
ram_node_type has been removed.
- Administrators can disable individual queue types; clients then cannot
declare new queues or streams of those types.
Removed or ignored settings and tools
- The management plugin no longer serves the
rabbitmqadmin v1 download.
Prefer the standalone rabbitmqadmin v2.
rabbitmq-streams set_stream_retention_policy is a no-op; set retention by
policy.
- The legacy all-in-one HTTP health check is a no-op; use focused checks.
tcp_listen_options.buffer is ignored because AMQP user-space TCP buffers
are auto-tuned. Kernel recbuf and sndbuf still apply.
- Remove ineffective
*.cacerts settings, but retain cacertfile where used.
- Remove the obsolete etcd TLS keys
fail_if_no_peer_cert, dh, and dhfile.
Queue and stream behavior to re-test
Quorum queues
- Quorum queues use 32 strict priority levels: every higher priority is
delivered before a lower one. This replaces the former two-level 2:1
interleaving behavior.
- Native delayed retries use
x-delayed-retry-type,
x-delayed-retry-min, and x-delayed-retry-max, or their policy forms.
- Requeue attempts increment
acquired-count, but only failures increment
delivery-count; poison-message limits therefore do not necessarily count
ordinary returns.
- Consumer timeout precedence is consumer argument, queue argument, policy,
then global
consumer_timeout. Timeouts affect quorum and Tanzu JMS queues,
not classic queues or streams.
consumer_disconnected_timeout defaults to 60 seconds before a partitioned
consumer's messages are returned. Policy and per-queue overrides exist.
- Delivery limits are policy-mutable. Purging also removes pending
at-least-once dead-lettered messages.
Streams
- AMQP 1.0 consumers can combine chunk-level filter values with broker-side
SQL expressions over message fields and application properties.
- Stream connections allow at most 256 publishers and 256 subscriptions.
- Before a successful
open, Stream frames default to an 8192-byte ceiling,
configurable with stream.initial_frame_max.
stream.max_uncompressed_sub_entry_batch_size defaults to 64 MiB; configure
publishers to the same decompression ceiling.
- A failed Stream OAuth renewal closes the connection, and the renewed token
is reauthorized for the active virtual host.
Exchanges and routing
- A topic binding key may contain at most two
# wildcards; prefer one final
# segment.
x-modulus-hash is now a core exchange and has restart-stable distribution
while bindings remain stable.
cluster_exchange_limit caps application declarations cluster-wide and
must have the same value on every node.
- The local-random exchange type can be disabled with
exchange_types.local_random.enabled = false.
Protocol compatibility checks
AMQP
- An AMQP 1.0 message without a header now uses the specification default
durable = false; send an explicit durable header when required.
- AMQP 1.0 supports dynamic nodes, Direct Reply-To, OAuth token renewal,
multiple routing keys through string-list annotation
x-cc, and stream
filters. Property filters are limited to 16 properties.
- AMQP 0-9-1 clients must offer a pre-authentication
frame_max of at least
- Node.js
amqplib should be 0.10.7 or newer.
- Credential refresh clears AMQP 0-9-1 permission caches, revalidates
consumers, and refreshes user tags. Passive declarations require
configure permission.
MQTT, STOMP, and WebSocket
- MQTT's default maximum packet size is 16 MiB and must not exceed the broker
max_message_size.
- MQTT 5 rejects packet-invalid properties and
Receive Maximum = 0, and
reports Quota exceeded when a queue length limit rejects a publish.
- Web MQTT enforces pre/post-authentication decompressed-frame ceilings,
login_timeout, and optional origin allowlists. Web STOMP enforces its frame
limit during accumulation.
- MQTT, STOMP, and Web MQTT stay blocked until all active resource alarms have
cleared.
- STOMP destinations affected by the transient non-exclusive queue removal use
exclusive queues.
Security and management checks
- Configure OAuth providers explicitly; do not rely on former Azure Entra or
Auth0 defaults. Discovery endpoints, scope aliases, selected variables, and
forwarded proxy headers are supported.
- Plain secrets containing a colon are not encrypted. Prefix supported
encrypted values with
encrypted:.
- A configured backend from a known but disabled authentication plugin causes
startup to fail.
- HTTP API authentication can use a backend chain separate from messaging
protocols. Protect the API reference and sensitive users where appropriate.
- Management actions that restart federation links or delete Shovels require
the
policymaker tag.
- When enabling encrypted management UI credentials, use the same
management.credential_encryption_secret on every node and wait until the
rolling upgrade is complete.
Operational validation
Before stopping a node, run:
rabbitmq-diagnostics check_if_node_is_quorum_critical
rabbitmq-upgrade await_online_quorum_plus_one
For metadata readiness and quorum leadership, use the focused diagnostics:
rabbitmq-diagnostics check_if_metadata_store_is_initialized
rabbitmq-diagnostics check_if_metadata_store_is_initialized_with_data
rabbitmq-diagnostics check_for_quorum_queues_without_an_elected_leader \
--vhost "vh-1" "^naming-pattern"
Also update 4.2-era Raft metric names and Grafana dashboards, clear stale
management UI browser state after an upgrade, and validate the exact deployed
configuration against the matching topic reference.
1---2name: rabbitmq-knowledge-patch3description: RabbitMQ4license: MIT5---678# RabbitMQ Knowledge Patch910Use this skill when upgrading or operating RabbitMQ, changing broker or plugin11configuration, integrating a protocol client, or updating monitoring and12automation. Determine the deployed RabbitMQ and Erlang/OTP versions first, then13open the reference that matches the task.1415## Reference index1617| Reference | Topics |18| --- | --- |19| [migrations-and-deprecations.md](references/migrations-and-deprecations.md) | Upgrade paths, rolling upgrades, Khepri migration, removed settings and deprecated features |20| [clustering-configuration-and-operations.md](references/clustering-configuration-and-operations.md) | Cluster formation, feature flags, resource alarms, health checks, limits, diagnostics, Erlang compatibility |21| [queues-streams-and-exchanges.md](references/queues-streams-and-exchanges.md) | Queue semantics, quorum queues, streams, exchange limits and routing behavior |22| [protocols-and-clients.md](references/protocols-and-clients.md) | AMQP 1.0, AMQP 0-9-1, MQTT, STOMP, WebSocket, Direct Reply-To, client behavior |23| [security-and-authentication.md](references/security-and-authentication.md) | OAuth/OIDC, LDAP, TLS, authentication backends, authorization, credential refresh |24| [management-api-and-observability.md](references/management-api-and-observability.md) | HTTP API, management UI, Prometheus metrics, logging, definition import/export |25| [federation-shovels-and-extensions.md](references/federation-shovels-and-extensions.md) | Federation, Shovels, plugin APIs, peer discovery, Tanzu features |2627## Upgrade decision points2829### Moving to 4.33031- Upgrade through 4.2.x; 4.3.x accepts upgrades only from 4.2.x.32- Enable all stable feature flags before the upgrade.33- Khepri is mandatory. Enable `khepri_db` before the first 4.3 node starts, or34 that node migrates Mnesia metadata during boot.35- If the cluster used AMQP 1.0 on 3.13 with `rabbitmq_amqp1_0` enabled, complete36 a rolling update after enabling `rabbitmq_4.0.0` and before entering 4.3.37- Keep a 4.3/4.2 mixed cluster only for the few hours required by a rolling38 upgrade.39- Run 4.3.x on Erlang/OTP 27.0 or later; older runtimes do not start.4041### Moving to 4.2 or 4.14243- 4.2 accepts direct upgrades from 4.1.x, 4.0.x, or 3.13.x. Existing Mnesia44 deployments remain on Mnesia until Khepri is explicitly enabled.45- 4.1 accepts 4.0.x or 3.13.x after all stable feature flags are enabled.46- A 3.13 cluster already using Khepri cannot upgrade in place to 4.x because47 the metadata format is incompatible; use a blue-green migration.48- Mixed-version clusters exist only for rolling upgrades. Do not enable49 release-specific features until every node has reached the new series.50- Do not use grow-then-shrink as a whole-cluster upgrade strategy; it changes51 replica identities and can cause large data transfers.5253## Breaking removals and defaults5455### Metadata and partition handling5657- 4.3 supports Khepri only. Remove Mnesia-era partition settings:58 `pause_if_all_down`, `pause_minority`, and `autoheal`.59- The accepted keys `cluster_partition_handling`,60 `cluster_partition_handling.pause_if_all_down.recover`, and61 `cluster_partition_handling.pause_if_all_down.nodes.$name` are inert.62- `rabbitmqctl force_reset` is deprecated because it is incompatible with63 Khepri.6465### Queues and deprecated features6667- Classic queue v1 storage is gone. Declarations fail if `x-queue-mode` has68 any value or `x-queue-version` is `1`; convert queues to CQv2 on 4.2 first.69- Non-durable, non-exclusive classic queues are rejected by default. Prefer a70 durable queue, an exclusive transient queue, or a durable queue with TTL.71 Temporary compatibility requires72 `deprecated_features.permit.transient_nonexcl_queues = true`.73- `amqp_address_v1`, `amqp_filter_set_bug`, `global_qos`, and74 `queue_master_locator` are denied unless explicitly permitted.75 `ram_node_type` has been removed.76- Administrators can disable individual queue types; clients then cannot77 declare new queues or streams of those types.7879### Removed or ignored settings and tools8081- The management plugin no longer serves the `rabbitmqadmin` v1 download.82 Prefer the standalone `rabbitmqadmin` v2.83- `rabbitmq-streams set_stream_retention_policy` is a no-op; set retention by84 policy.85- The legacy all-in-one HTTP health check is a no-op; use focused checks.86- `tcp_listen_options.buffer` is ignored because AMQP user-space TCP buffers87 are auto-tuned. Kernel `recbuf` and `sndbuf` still apply.88- Remove ineffective `*.cacerts` settings, but retain `cacertfile` where used.89- Remove the obsolete etcd TLS keys `fail_if_no_peer_cert`, `dh`, and `dhfile`.9091## Queue and stream behavior to re-test9293### Quorum queues9495- Quorum queues use 32 strict priority levels: every higher priority is96 delivered before a lower one. This replaces the former two-level 2:197 interleaving behavior.98- Native delayed retries use `x-delayed-retry-type`,99 `x-delayed-retry-min`, and `x-delayed-retry-max`, or their policy forms.100- Requeue attempts increment `acquired-count`, but only failures increment101 `delivery-count`; poison-message limits therefore do not necessarily count102 ordinary returns.103- Consumer timeout precedence is consumer argument, queue argument, policy,104 then global `consumer_timeout`. Timeouts affect quorum and Tanzu JMS queues,105 not classic queues or streams.106- `consumer_disconnected_timeout` defaults to 60 seconds before a partitioned107 consumer's messages are returned. Policy and per-queue overrides exist.108- Delivery limits are policy-mutable. Purging also removes pending109 at-least-once dead-lettered messages.110111### Streams112113- AMQP 1.0 consumers can combine chunk-level filter values with broker-side114 SQL expressions over message fields and application properties.115- Stream connections allow at most 256 publishers and 256 subscriptions.116- Before a successful `open`, Stream frames default to an 8192-byte ceiling,117 configurable with `stream.initial_frame_max`.118- `stream.max_uncompressed_sub_entry_batch_size` defaults to 64 MiB; configure119 publishers to the same decompression ceiling.120- A failed Stream OAuth renewal closes the connection, and the renewed token121 is reauthorized for the active virtual host.122123### Exchanges and routing124125- A topic binding key may contain at most two `#` wildcards; prefer one final126 `#` segment.127- `x-modulus-hash` is now a core exchange and has restart-stable distribution128 while bindings remain stable.129- `cluster_exchange_limit` caps application declarations cluster-wide and130 must have the same value on every node.131- The local-random exchange type can be disabled with132 `exchange_types.local_random.enabled = false`.133134## Protocol compatibility checks135136### AMQP137138- An AMQP 1.0 message without a header now uses the specification default139 `durable = false`; send an explicit durable header when required.140- AMQP 1.0 supports dynamic nodes, Direct Reply-To, OAuth token renewal,141 multiple routing keys through string-list annotation `x-cc`, and stream142 filters. Property filters are limited to 16 properties.143- AMQP 0-9-1 clients must offer a pre-authentication `frame_max` of at least144 8192. Node.js `amqplib` should be 0.10.7 or newer.145- Credential refresh clears AMQP 0-9-1 permission caches, revalidates146 consumers, and refreshes user tags. Passive declarations require147 `configure` permission.148149### MQTT, STOMP, and WebSocket150151- MQTT's default maximum packet size is 16 MiB and must not exceed the broker152 `max_message_size`.153- MQTT 5 rejects packet-invalid properties and `Receive Maximum = 0`, and154 reports `Quota exceeded` when a queue length limit rejects a publish.155- Web MQTT enforces pre/post-authentication decompressed-frame ceilings,156 `login_timeout`, and optional origin allowlists. Web STOMP enforces its frame157 limit during accumulation.158- MQTT, STOMP, and Web MQTT stay blocked until all active resource alarms have159 cleared.160- STOMP destinations affected by the transient non-exclusive queue removal use161 exclusive queues.162163## Security and management checks164165- Configure OAuth providers explicitly; do not rely on former Azure Entra or166 Auth0 defaults. Discovery endpoints, scope aliases, selected variables, and167 forwarded proxy headers are supported.168- Plain secrets containing a colon are not encrypted. Prefix supported169 encrypted values with `encrypted:`.170- A configured backend from a known but disabled authentication plugin causes171 startup to fail.172- HTTP API authentication can use a backend chain separate from messaging173 protocols. Protect the API reference and sensitive users where appropriate.174- Management actions that restart federation links or delete Shovels require175 the `policymaker` tag.176- When enabling encrypted management UI credentials, use the same177 `management.credential_encryption_secret` on every node and wait until the178 rolling upgrade is complete.179180## Operational validation181182Before stopping a node, run:183184```shell185rabbitmq-diagnostics check_if_node_is_quorum_critical186rabbitmq-upgrade await_online_quorum_plus_one187```188189For metadata readiness and quorum leadership, use the focused diagnostics:190191```shell192rabbitmq-diagnostics check_if_metadata_store_is_initialized193rabbitmq-diagnostics check_if_metadata_store_is_initialized_with_data194rabbitmq-diagnostics check_for_quorum_queues_without_an_elected_leader \195 --vhost "vh-1" "^naming-pattern"196```197198Also update 4.2-era Raft metric names and Grafana dashboards, clear stale199management UI browser state after an upgrade, and validate the exact deployed200configuration against the matching topic reference.