tests: declare durable queues so the suite runs on RabbitMQ 4.3+ - #1242
Open
syedusmanali wants to merge 1 commit into
Open
syedusmanali wants to merge 1 commit into
syedusmanali wants to merge 1 commit into
Conversation
RabbitMQ 4.3 moved the transient_nonexcl_queues deprecated feature from permitted_by_default to denied_by_default, so the broker now refuses non-durable, non-exclusive classic queues. Every functional test that declared a queue relied on queue_declare()'s defaults, which are durable=false and exclusive=false - exactly the combination that is refused. That is 32 errors, on every PHP version, because the refusal comes from the broker rather than from PHP. Turning durable on is the smallest change that fixes it: the queues stay non-exclusive and keep auto_delete, so visibility and cleanup are unchanged and only persistence differs. Declaring them exclusive would also satisfy the broker, but exclusive queues die with their connection, which breaks the tests that deliberately destroy connections - an exclusive queue there takes the shared auto-delete exchange down with it and the next test races the deletion. Verified against RabbitMQ 4.3.5 with nothing permitted, and against 3.13.7 for compatibility.
2 tasks
This branch has not been deployed
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
1 participant
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.
Fixes #1241
RabbitMQ 4.3 flipped the
transient_nonexcl_queuesdeprecated feature frompermitted_by_defaulttodenied_by_default, so the broker refuses non-durable, non-exclusive classic queues..ci/ubuntu/gha-setup.shpulls the unpinnedrabbitmq:managementtag, which now resolves to 4.3.x, and every functional test that declares a queue was takingqueue_declare()'s defaults -durable=false, exclusive=false, exactly the combination that's refused. That's 32 errors on every PHP version in the matrix.This turns
durableon at the 14 call sites that needed it. Nothing else changes: the queues stay non-exclusive and keepauto_delete, so visibility and cleanup behave as before and only persistence differs.Why durable and not exclusive
Declaring the queues exclusive also satisfies the broker, and I tried that first. It breaks the tests that deliberately destroy connections. An exclusive queue dies with its connection, which unbinds it, which auto-deletes the shared
test_exchange_broken(exchange_declaredefaults toauto_delete=true), and the next test then races that deletion and fails withNOT_FOUND - no exchange 'test_exchange_broken'. It's intermittent, which makes it worse.durableis also the smaller semantic change -exclusivealters both visibility and lifetime,durableonly alters persistence.Verification
OK- 864 tests, 1288 assertions, 0 failuresdocker-compose.yaml)OK- 864 tests, 1288 assertions, 0 failuresRun three times in a row on 4.3.5 against a reused broker, so the second and third runs re-declared queues that already existed as durable. No
inequivalent argproblems.vendor/bin/phpcsis clean.Worth knowing for anyone testing this locally: if you already have a broker holding a transient
reconnect_queuefrom before this change, your first run will hitPRECONDITION_FAILED - inequivalent arg 'durable'.ReconnectConnectionTest::tearDownCompatdeletes the queue, so it sorts itself out after one run. CI never sees it because the broker is fresh every time.On the tests requirement
CONTRIBUTING asks for tests with every patch and I can't really add one here, since the change is to the tests. The existing suite going from 32 errors to 0 against a strict broker is the only evidence this kind of change can offer.
Deliberately not in this PR
queue_declare()'s own defaults, which is the user-facing half of this and needs a maintainer decision - discussed in the issue.tests/rabbitmq.confanddocker-compose.yaml'srabbitmq:3-managementpin.listeners.tcp.default/listeners.ssl.defaultblock in.ci/ubuntu/rabbitmq.conf. Unrelated, and tidying it here would just muddy the diff.If you'd rather have CI green in one line while you review this,
deprecated_features.permit.transient_nonexcl_queues = truein.ci/ubuntu/rabbitmq.confdoes it, and I can send that separately. It's a stopgap though, since RabbitMQ intends to remove the feature regardless of config.