Conversation
|
This is an automated comment for commit fd5defd with description of existing statuses. It's updated for the latest CI running ✅ Click here to open a full report in a separate page Successful checks
|
|
Several recent failure samples:
All longer than 60 sec, so for those that PR should help. But there is also one different, @kssenii - may be you can check it? |
Seems to work. |
|
In the next commit after merge commit of this PR there is https://s3.amazonaws.com/clickhouse-test-reports/0/0cc5940fba34346f59d9e45dce3cab4e3e0bb4be/integration_tests__tsan__[2_6].html, seems different than before, so it could be because of this PR. |
|
Here I.e. the first failed test is test_rabbitmq_restore_failed_connection_without_losses_1. In rabbitmq logs ( Later according to clickhouse logs the query was executed It seems like a deadloop in the test here leading to the timeouts etc: ClickHouse/tests/integration/test_storage_rabbitmq/test.py Lines 2038 to 2042 in a23e807 and some issue with the queue after the RabbitMQ restart (maybe some change in the behavior of rabbitmq? Or somehow related to some of the plugins/feature flags which used to work before?) The last messages in RabbitMQ log is For sure it sounds like a good idea to add maximum number of iterations to the RabbitMQ tests, maybe it will not be killed then, and a better diagnostic will be possible. |
|
Changelog category:
Changelog entry:
Attempt to fix flaky RabbitMQ tests. Maybe closes #45160.
Documentation entry for user-facing changes:
It seems to just time out currently – see: #68694 (comment).
Changes:
rabbitmq_consistent_hash_exchange) we really need (should improve startup speed).for the record - local run