For 4.2.4: rabbit_logger_exchange_h: Always declare exchange, even if exchange logging is disabled (backport #15320)#15331
Merged
michaelklishin merged 4 commits intov4.2.xfrom Jan 22, 2026
Conversation
…ogging is disabled
[Why]
When the exchange logger handler is added, the broker is not ready to
declare the exchange.
The previous implementation used a temporary process that entered a loop
to wait for the broker to be ready and declare the exchange. It was
possible that definitions were imported before the exchange was
declared, leading to errors if bindings referenced it.
There was another problem: the exported definitions were dependent on
the exchange logger configuration:
* The default vhost under which the logger exchange is declared is
configurable.
* The logger exchange is only declared if the exchange logger handler is
enabled in the configuration.
Because of this, the import of definitions could fail if the
configuration of the node where the definitions are imported does not
enable the exchange logger handler.
[How]
This patch changes two things:
1. The logger exchange is always declared, regardless if exchange-based
logging is enabled or not. This also allows to get rid of the polling
in the setup process.
2. The logger exchange is included in the exported definitions.
This way, the exported definitions don't depend on any configuration on
the nodes they are imported in: the exported definitions are
self-contained and know about this logger exchange.
Part 1 could be enough to fix the problem on RabbitMQ version that
include this patch. Part 2 allows to fix the problem when definitions
are exported from a version with this patch and are imported on a
version without.
V2: Ignore the failure to declare the exchange. It should probably not
be the only logger configured because there is a chicken-and-egg
loop with it. It should not block the broker from starting.
(cherry picked from commit a908504)
# Conflicts:
# deps/rabbit/src/rabbit_logger_exchange_h.erl
(cherry picked from commit 0ec0df1)
Author
|
Cherry-pick of a908504 has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
michaelklishin
added a commit
that referenced
this pull request
Jan 22, 2026
All of our efforts go into 'rabbitmqadmin' v2 [1][2], updating 'rabbitmqadmin` v1 tests (e.g. in #15331) feels like busywork and completely unnecessary. 1. https://github.com/rabbitmq/rabbitmqadmin-ng 2. https://www.rabbitmq.com/docs/management-cli
All of our efforts go into 'rabbitmqadmin' v2 [1][2], updating 'rabbitmqadmin` v1 tests (e.g. in #15331) feels like busywork and completely unnecessary. 1. https://github.com/rabbitmq/rabbitmqadmin-ng 2. https://www.rabbitmq.com/docs/management-cli (cherry picked from commit 94702b3)
michaelklishin
added a commit
that referenced
this pull request
Jan 22, 2026
All of our efforts go into 'rabbitmqadmin' v2 [1][2], updating 'rabbitmqadmin` v1 tests (e.g. in #15331) feels like busywork and completely unnecessary. 1. https://github.com/rabbitmq/rabbitmqadmin-ng 2. https://www.rabbitmq.com/docs/management-cli (cherry picked from commit 94702b3)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
When the exchange logger handler is added, the broker is not ready to declare the exchange.
The previous implementation used a temporary process that entered a loop to wait for the broker to be ready and declare the exchange. It was possible that definitions were imported before the exchange was declared, leading to errors if bindings referenced it.
There was another problem: the exported definitions were dependent on the exchange logger configuration:
Because of this, the import of definitions could fail if the configuration of the node where the definitions are imported does not enable the exchange logger handler.
How
This patch changes two things:
The logger exchange is always declared, regardless if exchange-based logging is enabled or not. This also allows to get rid of the polling in the setup process.
The logger exchange is included in the exported definitions.
This way, the exported definitions don't depend on any configuration on the nodes they are imported in: the exported definitions are self-contained and know about this logger exchange.
Part 1 could be enough to fix the problem on RabbitMQ version that include this patch. Part 2 allows to fix the problem when definitions are exported from a version with this patch and are imported on a version without.
This is an automatic backport of pull request #15320 done by Mergify.