Repository navigation
feat: tolerate queue declares that don't match the existing queue (DS-3366) - #81
Merged
Merged
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Concurrent declarations can exhaust the connection’s negotiated channel limit.
1 open finding
What changed in this PR
Isolates queue declarations so mismatches do not disconnect existing consumers during queue migrations.
Changes:
- Declares queues on short-lived channels and tolerates existing-queue mismatches.
- Adds integration coverage for mismatches and declaration errors.
- Documents tolerant declarations and release behavior.
| File | Description |
|---|---|
ts/rabbit.ts |
Associates channels with their connection. |
ts/queue.ts |
Implements isolated, tolerant declarations. |
ts/channel.ts |
Adds connection metadata to channels. |
test/rabbit.test.ts |
Covers mismatch and error scenarios. |
test/queue.test.ts |
Updates declaration spying. |
README.md |
Documents the new behavior. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
ikarachristos
force-pushed
the
feature/DS-3366-tolerant-queue-declares
branch
from
October 13, 2026 06:34
0da3da1 to
ca68b5e
Compare
nikosd23
reviewed
Oct 13, 2026
…-3366) Declare each queue on a short-lived channel. On a 406 for a queue that exists with different arguments, log a warning and consume the queue as it is, instead of closing the shared consume channel and disconnecting every consumer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Startup declares run concurrently, and each one now opens its own channel, so a service with many queues could exhaust the connection's channel_max. Cap declare channels at 10 per connection; further declares wait for a slot. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The cap of 10 ignored the consume channel already open on the connection, so a broker with channel_max of 10 or less could still run out of channels. Derive the cap from the negotiated channelMax, reserving the consume channel. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…(DS-3366) Tolerating every 406 hid mismatches the migration doesn't need, such as a delay queue whose dead-letter routing key changed. Only x-queue-type and x-max-priority are tolerated now, and only with the new tolerateQueueTypeMismatch option, which is off by default. The broker reports one mismatch at a time and checks a quorum queue's type before its TTL and delivery limit, so after a tolerated mismatch the queue is redeclared with its current value to let the broker check the rest. Binds and unbinds also run on short-lived channels, so a failed bind rejects without closing the consume channel. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ikarachristos
force-pushed
the
feature/DS-3366-tolerant-queue-declares
branch
from
October 13, 2026 07:11
63a4b12 to
fa29561
Compare
nikosd23
approved these changes
Oct 13, 2026
ikarachristos
added a commit
that referenced
this pull request
Oct 13, 2026
…quorum Keeps both options next to each other: scheduledPublishQueuesAsQuorum from this PR and tolerateQueueTypeMismatch from #81. 5.10.0 shipped without this PR, so its changelog entry moves to 5.11.x. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Why
We're converting our queues from classic to quorum before the RabbitMQ 4 upgrade (DS-3366). During a rolling deploy, old and new pods declare the same queue with different arguments (classic vs quorum, with or without priority). RabbitMQ rejects the mismatched declare and closes the channel it ran on.
Today every declare runs on the shared consume channel, so one rejected declare drops every consumer in the service, and orka's reconnect loop hits the same rejection again. Old and new pods keep knocking each other over.
What changes
createQueue, but the other consumers stay connected.Queues built on a caller's own channel, such asMigrator's, behave as before.Released as 5.x (minor), not 6.0: orka depends on
rabbit-queue ^5.9.2, and a major version would install a second copy alongside it. Changelog entry added for the other teams on the vhost.Testing
New integration tests cover an existing queue declared with a different type or priority (both directions), invalid arguments on a new queue, and a non-406 error. Each test checks that messages are still consumed and nothing disconnects. Without this change, the first one fails with the consume connection closed. The full suite passes on RabbitMQ 3.13.7 and 4.2.1.
🤖 Generated with Claude Code