[Why]
The `longnames`-based testcase depends on a copnfigured FQDN. Buildbuddy
hosts were incorrectly configured and were lacking one. As a workaround,
`/etc/hosts` was modified to add an FQDN.
We don't use Buildbuddy anymore, but the problem also appeared on team
members' Broadcom-managed laptops (also having an incomplete network
configuration). More importantly, GitHub workers seem to have the same
problem, but randomly!
At this point, we can't rely on the host's correct network
configuration.
[How]
The testsuite is modified to use a hard-coded IP address, 127.0.0.1, to
simulate a long Erlang node name (i.e. it has dots).
When FAST_RUN_BROKER=1 was introduced it helped reduce the
time to run the broker, but mistakenly was always starting
all plugins even when running run-broker against a specific
plugin, for example `make -C deps/rabbitmq_management run-broker`.
Starting broker... completed with 36 plugins.
With this commit only the target plugin (and its dependencies)
will be started.
Starting broker... completed with 3 plugins.
This also has a positive effect on start performance:
make -C deps/rabbitmq_management run-broker 2,28s user 2,11s system 88% cpu 4,943 total
make -C deps/rabbitmq_management run-broker 2,00s user 1,61s system 94% cpu 3,807 total
We want to be strict for tests. Only the code that should
be available when testing a plugin should be made available.
With FAST_RUN_BROKER=1, for the time being, this is not the
case: all plugins' code is available to be loaded.
In case 16, an await_condition/2 condition was
not correctly matching the error. As a result,
the function proceeded to the assertion step
earlier than it should have, failing with
an obscure function_clause.
This was because an {error, Context} clause
was not correct.
In addition to fixing it, this change adds a
catch-all clause and verifies the loaded
tagged virtual host before running any assertions
on it.
If the virtual host was not imported, case 16
will now fail with a specific CT log message.
References #11457 because the changes there
exposed this behavior in CI.
Importing a definitions file with no `default_queue_type` metadata for a vhost will result in that vhosts value being set to `undefined`.
Once set to a non-`undefined` value, this PR prevents `default_queue_type` from being set back to `undefined`
build(deps): bump org.springframework.boot:spring-boot-starter-parent from 3.3.0 to 3.3.1 in /deps/rabbitmq_auth_backend_http/examples/rabbitmq_auth_backend_spring_boot_kotlin
build(deps): bump org.springframework.boot:spring-boot-starter-parent from 3.3.0 to 3.3.1 in /deps/rabbitmq_auth_backend_http/examples/rabbitmq_auth_backend_spring_boot
ra_state may contain a QQ state such as {'foo',init,unknown}.
Perfore this fix, all_replica_states doesn't map such states
to a 2-tuple which leads to a crash in maps:from_list because
a 3-tuple can't be handled.
A crash in rabbit_quorum_queue:all_replica_states leads to no
results being returned from a given node when the CLI asks for
QQs with minimum quorum.
This reverts commit 8749c605f5.
[Why]
The patch was supposed to solve an issue that we didn't understand and
that was likely a network/DNS problem outside of RabbitMQ. We know it
didn't solve that issue because it was reported again 6 months after the
initial pull request (#8411).
What we are sure however is that it increased the testing of RabbitMQ
significantly because the code loops for 10+ minutes if the remote node
is not running.
The retry in the Feature flags subsystem was not the right place either.
The `noconnection` error is visible there because it runs earlier during
RabbitMQ startup. But retrying there won't solve a network issue
magically.
There are two ways to create a cluster:
1. peer discovery and this subsystem takes care of retries if necessary
and appropriate
2. manually using the CLI, in which case the user is responsible for
starting RabbitMQ nodes and clustering them
Let's revert it until the root cause is really understood.