Codecov Report

❌ Patch coverage is 85.18519% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.63%. Comparing base (31d05ed) to head (213104e).
⚠️ Report is 70 commits behind head on main.

@@           Coverage Diff           @@
##             main    #9815   +/-   ##
=======================================
  Coverage   78.63%   78.63%           
=======================================
  Files         153      153           
  Lines       19199    19222   +23     
  Branches     2546     2555    +9     
=======================================
+ Hits        15097    15116   +19     
- Misses       3807     3810    +3     
- Partials      295      296    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hi @auvipy I just open the PR on Kombu

I added to the control.py file on the celery part the two parameter control_queue_durable and control_queue_exclusive, after kombu is fixed i will make the commit with these modifications.

can you please also look at the approach in this PR? celery/kombu#2313 and #9750 ? are they related to what you are trying to do?

I checked both of those drafts. They flip every queue to durable=True, so the RabbitMQ warning disappears. For what I undestand pidbox queues are meant for short-lived messages that you don't need to keep after the broker is restarted.

My patch keeps the current behaviour unless the user asks for something different. It adds two flags: you can set the pidbox queue to exclusive (still transient, but now accepted by RabbitMQ 4.x) or, if you really need persistence, you can set it to durable. If you do nothing, it stays exactly as it is today.

If the project would rather move straight to the “everything durable” solution, I can drop this and follow that path o set is as default as durable=True

Please let me know if I’ve misunderstood anything.

your approach seems better so im ok with it.

Hi @auvipy

I’ve added support for configuring durable and exclusive options on both event queues and control queue:

• event_queue_durable, event_queue_exclusive
• control_queue_durable, control_queue_exclusive

There’s also validation to prevent both being set to True, plus I added docs and tests. This is meant to fix #9759 on the celery part.

That said, I can’t fully test the changes because they depend on feature that we introduced in Kombu PR 2338

Just wondering what’s the best way to proceed here, i need some guidance on how i can test it or if is necessary to test with the right version of kombu.

Thanks!

can you check why the unit tests are failing, please?

My bad, I’ve just pushed a follow‑up commit that adds the missing guard clause to the failing test I introduced.

Also figured out how to pin my local env to the unreleased kombu main, so I run the full test‑suite and the CI should be green.

I think the tests are now failing because they are not pointing to the main of Kombu, I think i need some guidance here to understand how to fix them.

yes kombu new version is required.

kombu has been updated, so lets see

the redis failures are not related to this rabbitmq bug fix pr

@ghirailghiro please address the review comments...

unit tests seems to be failing after the last commit. can you please cross check and fix them?

I checked the celery/app/amqp.py on main and i think the right way is to explicit set the routing_key. I think we should roll back the last commit for keeping compatibility.

🚀🚀

Thank you guys for the support and sorry for the delay on the response!