Make CI known flakes and errors #12413
Labels
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
And And other test cases in that same suite. |
|
|
|
When this flake occurs, the RabbitMQ logs for this test show as expected: Deleted this F# test since it's redundant: #12581 |
And |
|
|
ansd
added a commit
that referenced
this issue
Oct 23, 2024
This commit attempts to eliminate the test flake described in #12413 (comment) ``` rabbitmq_mqtt > parallel-ct-set-1 > mqtt_shared_SUITE > cluster_size_3 > v4 rabbit_mqtt_qos0_queue_kill_node === Ended at 2024-10-01 09:59:52 === Location: [{mqtt_shared_SUITE,rabbit_mqtt_qos0_queue_kill_node,[1165](https://github.com/rabbitmq/rabbitmq-server/issues/mqtt_shared_suite.src.html#1165)}, {test_server,ts_tc,1793}, {test_server,run_test_case_eval1,1302}, {test_server,run_test_case_eval,1234}] === === Reason: no match of right hand side value {publish_not_received, <<"m1">>} in function mqtt_shared_SUITE:rabbit_mqtt_qos0_queue_kill_node/1 (mqtt_shared_SUITE.erl, line 1165) in call from test_server:ts_tc/3 (test_server.erl, line 1793) in call from test_server:run_test_case_eval1/6 (test_server.erl, line 1302) in call from test_server:run_test_case_eval/9 (test_server.erl, line 1234) ``` This flake could not be reproduced locally. This commit also assumes that this flake occurred under Khepri but not under Mnesia. The hypothesis is the following: * Node 0 is down * MQTT client creates binding on node 1 * Khepri commits since the binding is replicated and persisted on node 1 and node 2. However the binding isn't reflected yet in node 2's routing projecting table. * Publishing a message to node 2 routes to nowhere.
ansd
added a commit
that referenced
this issue
Oct 23, 2024
This commit attempts to eliminate the test flake described in #12413 (comment) ``` rabbitmq_mqtt > parallel-ct-set-1 > mqtt_shared_SUITE > cluster_size_3 > v4 rabbit_mqtt_qos0_queue_kill_node === Ended at 2024-10-01 09:59:52 === Location: [{mqtt_shared_SUITE,rabbit_mqtt_qos0_queue_kill_node,[1165](https://github.com/rabbitmq/rabbitmq-server/issues/mqtt_shared_suite.src.html#1165)}, {test_server,ts_tc,1793}, {test_server,run_test_case_eval1,1302}, {test_server,run_test_case_eval,1234}] === === Reason: no match of right hand side value {publish_not_received, <<"m1">>} in function mqtt_shared_SUITE:rabbit_mqtt_qos0_queue_kill_node/1 (mqtt_shared_SUITE.erl, line 1165) in call from test_server:ts_tc/3 (test_server.erl, line 1793) in call from test_server:run_test_case_eval1/6 (test_server.erl, line 1302) in call from test_server:run_test_case_eval/9 (test_server.erl, line 1234) ``` This flake could not be reproduced locally. This commit also assumes that this flake occurred under Khepri but not under Mnesia. The hypothesis is the following: * Node 0 is down * MQTT client creates binding on node 1 * Khepri commits since the binding is replicated and persisted on node 1 and node 2. However the binding isn't reflected yet in node 2's routing projecting table. * Publishing a message to node 2 routes to nowhere. (cherry picked from commit 17df1b9)
ansd
added a commit
that referenced
this issue
Oct 24, 2024
As described in #12413 (comment) test case queue_topology flaked in CI with the following error: ``` rabbitmq_amqp_client > management_SUITE > cluster_size_3 > queue_topology #1. {error,{test_case_failed,{824, <<"rmq-ct-cluster_size_3-1-21000@localhost">>}}} ``` This flake could not be reproduced locally (neither with Mnesia nor with Khepri).
ansd
added a commit
that referenced
this issue
Oct 24, 2024
As described in #12413 (comment) test case queue_topology flaked in CI with the following error: ``` rabbitmq_amqp_client > management_SUITE > cluster_size_3 > queue_topology #1. {error,{test_case_failed,{824, <<"rmq-ct-cluster_size_3-1-21000@localhost">>}}} ``` This flake could not be reproduced locally (neither with Mnesia nor with Khepri). (cherry picked from commit 8c046c7)
ansd
added a commit
that referenced
this issue
Oct 24, 2024
in order to troubleshoot the flake described in #12413 (comment) ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received\n at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477\n at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ```
ansd
added a commit
that referenced
this issue
Oct 24, 2024
in order to troubleshoot the flake described in #12413 (comment) ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received\n at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477\n at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ``` (cherry picked from commit 0c905f9)
ansd
added a commit
that referenced
this issue
Oct 24, 2024
This test flakes in CI as described in #12413 (comment) The test case fails with ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477 at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ``` However, RabbitMQ closes the session as expected due to the missing read permissions to the queue as shown in the RabbitMQ logs: ``` [debug] <0.1321.0> Asked to create a new user 'access_failure', password length in bytes: 24 [info] <0.1321.0> Created user 'access_failure' [debug] <0.1324.0> Asked to set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1324.0> Successfully set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1333.0> accepting AMQP connection 127.0.0.1:36248 -> 127.0.0.1:25000 [debug] <0.1333.0> User 'access_failure' authenticated successfully by backend rabbit_auth_backend_internal [info] <0.1333.0> Connection from AMQP 1.0 container 'AMQPNetLite-101d7d51': user 'access_failure' authenticated using SASL mechanism PLAIN and granted access to vhost '/' [debug] <0.1333.0> AMQP 1.0 connection.open frame: hostname = 127.0.0.1, extracted vhost = /, idle-time-out = undefined [debug] <0.1333.0> AMQP 1.0 created session process <0.1338.0> for channel number 0 [warning] <0.1338.0> Closing session for connection <0.1333.0>: {'v1_0.error', [warning] <0.1338.0> {symbol, [warning] <0.1338.0> <<"amqp:unauthorized-access">>}, [warning] <0.1338.0> {utf8, [warning] <0.1338.0> <<"read access to queue 'test' in vhost '/' refused for user 'access_failure'">>}, [warning] <0.1338.0> undefined} [debug] <0.1333.0> AMQP 1.0 closed session process <0.1338.0> with channel number 0 [warning] <0.1333.0> closing AMQP connection <0.1333.0> (127.0.0.1:36248 -> 127.0.0.1:25000, duration: '269ms'): [warning] <0.1333.0> client unexpectedly closed TCP connection ``` ``` let receiver = ReceiverLink(ac.Session, "test-receiver", src) ``` uses a null constructur for the onAttached callback. ReceiverLink doesn't seem to block. Given that the exact same authorization error is already tested in test case attach_source_queue of amqp_auth_SUITE, it's safe to delete this F# test.
ansd
added a commit
that referenced
this issue
Oct 24, 2024
This test flakes in CI as described in #12413 (comment) The test case fails with ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477 at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ``` However, RabbitMQ closes the session as expected due to the missing read permissions to the queue as shown in the RabbitMQ logs: ``` [debug] <0.1321.0> Asked to create a new user 'access_failure', password length in bytes: 24 [info] <0.1321.0> Created user 'access_failure' [debug] <0.1324.0> Asked to set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1324.0> Successfully set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1333.0> accepting AMQP connection 127.0.0.1:36248 -> 127.0.0.1:25000 [debug] <0.1333.0> User 'access_failure' authenticated successfully by backend rabbit_auth_backend_internal [info] <0.1333.0> Connection from AMQP 1.0 container 'AMQPNetLite-101d7d51': user 'access_failure' authenticated using SASL mechanism PLAIN and granted access to vhost '/' [debug] <0.1333.0> AMQP 1.0 connection.open frame: hostname = 127.0.0.1, extracted vhost = /, idle-time-out = undefined [debug] <0.1333.0> AMQP 1.0 created session process <0.1338.0> for channel number 0 [warning] <0.1338.0> Closing session for connection <0.1333.0>: {'v1_0.error', [warning] <0.1338.0> {symbol, [warning] <0.1338.0> <<"amqp:unauthorized-access">>}, [warning] <0.1338.0> {utf8, [warning] <0.1338.0> <<"read access to queue 'test' in vhost '/' refused for user 'access_failure'">>}, [warning] <0.1338.0> undefined} [debug] <0.1333.0> AMQP 1.0 closed session process <0.1338.0> with channel number 0 [warning] <0.1333.0> closing AMQP connection <0.1333.0> (127.0.0.1:36248 -> 127.0.0.1:25000, duration: '269ms'): [warning] <0.1333.0> client unexpectedly closed TCP connection ``` ``` let receiver = ReceiverLink(ac.Session, "test-receiver", src) ``` uses a null constructur for the onAttached callback. ReceiverLink doesn't seem to block. Given that the exact same authorization error is already tested in test case attach_source_queue of amqp_auth_SUITE, it's safe to delete this F# test.
mergify bot
pushed a commit
that referenced
this issue
Oct 24, 2024
This test flakes in CI as described in #12413 (comment) The test case fails with ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477 at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ``` However, RabbitMQ closes the session as expected due to the missing read permissions to the queue as shown in the RabbitMQ logs: ``` [debug] <0.1321.0> Asked to create a new user 'access_failure', password length in bytes: 24 [info] <0.1321.0> Created user 'access_failure' [debug] <0.1324.0> Asked to set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1324.0> Successfully set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1333.0> accepting AMQP connection 127.0.0.1:36248 -> 127.0.0.1:25000 [debug] <0.1333.0> User 'access_failure' authenticated successfully by backend rabbit_auth_backend_internal [info] <0.1333.0> Connection from AMQP 1.0 container 'AMQPNetLite-101d7d51': user 'access_failure' authenticated using SASL mechanism PLAIN and granted access to vhost '/' [debug] <0.1333.0> AMQP 1.0 connection.open frame: hostname = 127.0.0.1, extracted vhost = /, idle-time-out = undefined [debug] <0.1333.0> AMQP 1.0 created session process <0.1338.0> for channel number 0 [warning] <0.1338.0> Closing session for connection <0.1333.0>: {'v1_0.error', [warning] <0.1338.0> {symbol, [warning] <0.1338.0> <<"amqp:unauthorized-access">>}, [warning] <0.1338.0> {utf8, [warning] <0.1338.0> <<"read access to queue 'test' in vhost '/' refused for user 'access_failure'">>}, [warning] <0.1338.0> undefined} [debug] <0.1333.0> AMQP 1.0 closed session process <0.1338.0> with channel number 0 [warning] <0.1333.0> closing AMQP connection <0.1333.0> (127.0.0.1:36248 -> 127.0.0.1:25000, duration: '269ms'): [warning] <0.1333.0> client unexpectedly closed TCP connection ``` ``` let receiver = ReceiverLink(ac.Session, "test-receiver", src) ``` uses a null constructur for the onAttached callback. ReceiverLink doesn't seem to block. Given that the exact same authorization error is already tested in test case attach_source_queue of amqp_auth_SUITE, it's safe to delete this F# test. (cherry picked from commit b1169d0)
ansd
added a commit
that referenced
this issue
Oct 24, 2024
This test flakes in CI as described in #12413 (comment) The test case fails with ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477 at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ``` However, RabbitMQ closes the session as expected due to the missing read permissions to the queue as shown in the RabbitMQ logs: ``` [debug] <0.1321.0> Asked to create a new user 'access_failure', password length in bytes: 24 [info] <0.1321.0> Created user 'access_failure' [debug] <0.1324.0> Asked to set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1324.0> Successfully set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1333.0> accepting AMQP connection 127.0.0.1:36248 -> 127.0.0.1:25000 [debug] <0.1333.0> User 'access_failure' authenticated successfully by backend rabbit_auth_backend_internal [info] <0.1333.0> Connection from AMQP 1.0 container 'AMQPNetLite-101d7d51': user 'access_failure' authenticated using SASL mechanism PLAIN and granted access to vhost '/' [debug] <0.1333.0> AMQP 1.0 connection.open frame: hostname = 127.0.0.1, extracted vhost = /, idle-time-out = undefined [debug] <0.1333.0> AMQP 1.0 created session process <0.1338.0> for channel number 0 [warning] <0.1338.0> Closing session for connection <0.1333.0>: {'v1_0.error', [warning] <0.1338.0> {symbol, [warning] <0.1338.0> <<"amqp:unauthorized-access">>}, [warning] <0.1338.0> {utf8, [warning] <0.1338.0> <<"read access to queue 'test' in vhost '/' refused for user 'access_failure'">>}, [warning] <0.1338.0> undefined} [debug] <0.1333.0> AMQP 1.0 closed session process <0.1338.0> with channel number 0 [warning] <0.1333.0> closing AMQP connection <0.1333.0> (127.0.0.1:36248 -> 127.0.0.1:25000, duration: '269ms'): [warning] <0.1333.0> client unexpectedly closed TCP connection ``` ``` let receiver = ReceiverLink(ac.Session, "test-receiver", src) ``` uses a null constructur for the onAttached callback. ReceiverLink doesn't seem to block. Given that the exact same authorization error is already tested in test case attach_source_queue of amqp_auth_SUITE, it's safe to delete this F# test. (cherry picked from commit b1169d0)
michaelklishin
pushed a commit
that referenced
this issue
Oct 25, 2024
As described in #12413 (comment) test case queue_topology flaked in CI with the following error: ``` rabbitmq_amqp_client > management_SUITE > cluster_size_3 > queue_topology #1. {error,{test_case_failed,{824, <<"rmq-ct-cluster_size_3-1-21000@localhost">>}}} ``` This flake could not be reproduced locally (neither with Mnesia nor with Khepri).
michaelklishin
pushed a commit
that referenced
this issue
Oct 25, 2024
in order to troubleshoot the flake described in #12413 (comment) ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received\n at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477\n at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ```
michaelklishin
pushed a commit
that referenced
this issue
Nov 4, 2024
As described in #12413 (comment) test case queue_topology flaked in CI with the following error: ``` rabbitmq_amqp_client > management_SUITE > cluster_size_3 > queue_topology #1. {error,{test_case_failed,{824, <<"rmq-ct-cluster_size_3-1-21000@localhost">>}}} ``` This flake could not be reproduced locally (neither with Mnesia nor with Khepri).
michaelklishin
pushed a commit
that referenced
this issue
Nov 4, 2024
in order to troubleshoot the flake described in #12413 (comment) ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received\n at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477\n at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ```
michaelklishin
pushed a commit
that referenced
this issue
Nov 4, 2024
This test flakes in CI as described in #12413 (comment) The test case fails with ``` Node: rabbit_shard2@localhost Case: amqp_system_SUITE:access_failure Reason: {error,{{badmatch,{error,134, "Unhandled exception. System.Exception: expected exception not received at Program.Test.accessFailure(String uri) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 477 at Program.main(String[] argv) in /home/runner/work/rabbitmq-server/rabbitmq-server/deps/rabbit/test/amqp_system_SUITE_data/fsharp-tests/Program.fs:line 509\n"}}, [{amqp_system_SUITE,run_dotnet_test,2, [{file,"amqp_system_SUITE.erl"}, {line,257}]}, ``` However, RabbitMQ closes the session as expected due to the missing read permissions to the queue as shown in the RabbitMQ logs: ``` [debug] <0.1321.0> Asked to create a new user 'access_failure', password length in bytes: 24 [info] <0.1321.0> Created user 'access_failure' [debug] <0.1324.0> Asked to set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1324.0> Successfully set permissions for user 'access_failure' in virtual host '/' to '.*', '^banana.*', '^banana.*' [info] <0.1333.0> accepting AMQP connection 127.0.0.1:36248 -> 127.0.0.1:25000 [debug] <0.1333.0> User 'access_failure' authenticated successfully by backend rabbit_auth_backend_internal [info] <0.1333.0> Connection from AMQP 1.0 container 'AMQPNetLite-101d7d51': user 'access_failure' authenticated using SASL mechanism PLAIN and granted access to vhost '/' [debug] <0.1333.0> AMQP 1.0 connection.open frame: hostname = 127.0.0.1, extracted vhost = /, idle-time-out = undefined [debug] <0.1333.0> AMQP 1.0 created session process <0.1338.0> for channel number 0 [warning] <0.1338.0> Closing session for connection <0.1333.0>: {'v1_0.error', [warning] <0.1338.0> {symbol, [warning] <0.1338.0> <<"amqp:unauthorized-access">>}, [warning] <0.1338.0> {utf8, [warning] <0.1338.0> <<"read access to queue 'test' in vhost '/' refused for user 'access_failure'">>}, [warning] <0.1338.0> undefined} [debug] <0.1333.0> AMQP 1.0 closed session process <0.1338.0> with channel number 0 [warning] <0.1333.0> closing AMQP connection <0.1333.0> (127.0.0.1:36248 -> 127.0.0.1:25000, duration: '269ms'): [warning] <0.1333.0> client unexpectedly closed TCP connection ``` ``` let receiver = ReceiverLink(ac.Session, "test-receiver", src) ``` uses a null constructur for the onAttached callback. ReceiverLink doesn't seem to block. Given that the exact same authorization error is already tested in test case attach_source_queue of amqp_auth_SUITE, it's safe to delete this F# test.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This ticket is meant to track down flakes and errors that happen in Make CI (currently enabled in
mainand pull requests.OTP-27 bugs
inetrcKernel parameter doesn't accept atoms anymore on 27 (resolution in OTP-27 inetrc behavior change leads to obscure crashes erlang/otp#8899 fixed in upcoming 27.1.3)java_SUITEofrabbitmq_mqtt, and Erlang/OTP 27.1.1 (specifically) - (resolution in SSL version matching OTP 27.1.1 erlang/otp#8908 fixed in 27.1.2)Flakes
Failed to create SSL certificates- multiple test suites, one example in commentrabbit > amqp_system > access_failure- details in commentrabbit > metrics_SUITE > connection_metric_count_test- details in commentrabbit > per_node_limit_SUITE > channel_consumers_limit- details in commentrabbitmq_amqp_client > management_SUITE > cluster_size_3 > queue_topology- details in comment - possibly solved via 8c046c7rabbitmq_amqp_client > management_SUITE > cluster_size_3 > classic_queue_stopped- details in commentrabbitmq_clisometimes fails with1383 tests, 5 failures- the failures are all tests that set the disk free limit. It is not yet known whether they are proper errors, normal flakes or caused by differences in GH runnersrabbitmq_federation > exchange_SUITE > rolling_upgrade > child_id_format- timetrap timeoutrabbitmq_federation > queue_SUITE > classic_queue > without_disambiguate > cluster_size_1 > dynamic_plugin_stop_start- details in commentrabbitmq_management > clustering_SUITE > non_parallel_tests > queue_on_other_node- details in commentrabbitmq_management > clustering_prop_SUITE > non_parallel_tests > prop_connection_channel_counts_test- details in commentrabbitmq_mqtt > parallel-ct-set-1 > mqtt_shared_SUITE > cluster_size_3 > v4 rabbit_mqtt_qos0_queue_kill_node- test failure (details in comment) leads to subsequent tests being unable to continue and to the job timing out after 30 minutes. Possibly solved via 17df1b9The text was updated successfully, but these errors were encountered: