Conversation
niemyjski
left a comment
niemyjski
left a comment
There was a problem hiding this comment.
AI-assisted reviewer assessment
Acknowledged and reviewed the endpoint implementation, provider call sites, TLS/identity contract, constructor regressions, infrastructure policy, live TLS tests, relay lifecycle, workflow result validation, and compatibility documentation. This assessment is submitted through the author's connected account; it is not an independent human approval or a bypass of repository review requirements.
Verified findings
- The production runtime change remains scoped to constructing validated TLS-aware endpoints after ConnectionFactory.Uri is parsed. Publisher and subscriber connection creation both use those endpoints; acknowledgement, retry, and recovery defaults were not changed.
- Certificate validation remains strict. The negative cases distinguish wrong identity from an untrusted issuing chain and bracket failures with healthy controls.
- New established-session tests observe real publisher/subscriber shutdown and recovery, retain an identified event in the shared broker during a complete relay-path outage, restore only the alternative endpoint, assert the target changed endpoint, and verify pending and post-recovery message IDs. Relays forward opaque TCP and do not terminate TLS.
- IPv4 and IPv6 URI/replacement-host cases execute real publish/subscribe traffic over dynamically allocated non-default ports.
- Downloaded and inspected the report for run 35749013178: 12 passed, 0 failed, 0 skipped, 0 pending, 0 other. Both targeted recovery cases and all four custom-port/IPv6 cases are individually present and passed. Tested merge ref:
2c6d352169d840c2eb0059ba48eff7a6c4220717. - Branch comparison at the time of review showed the branch includes the current main base
aa062848eafaa04d8d1309f382b823f67bd68c41(zero commits behind).
Release blockers / limitations
Full integration is still not approved. The original full run failed during required infrastructure startup. The seed discovery configuration has been corrected, and a stricter full-suite workflow now preserves individual results and refuses skipped broker cases. Its first execution exposed an invalid runner exclusion switch before tests ran; that command is corrected against the xUnit parser (-class-) in e02e615. A runner-command error is not behavioral test evidence.
The passing relay cases prove endpoint-loss recovery against a shared TLS broker, not replicated-queue availability after broker-node loss. Observed runtime/platform coverage is Linux/.NET 10/RabbitMQ 4.2.0; .NET 8 compilation is not .NET 8 execution evidence. Broader retry, terminal-message, channel-only recovery, and durability repairs remain in #99.
Disposition: keep draft until a complete final-candidate integration report passes. The established-session TLS and live custom-port/IPv6 gaps are now covered by executed passing cases. Final integration evidence and any additional findings must be recorded before a release recommendation.
niemyjski
left a comment
niemyjski
left a comment
There was a problem hiding this comment.
AI-assisted reviewer ACK / final execution hold
Reviewed candidate 3a31afd927a1eec1e52b6788998b344dca730409, including the endpoint integration, strict certificate policy, live recovery tests, required infrastructure policy, redelivery regression, priority-argument correction and priority test setup, workflow result gates, and documentation. Re-read PR conversation feedback and compared the branch to current main: zero commits behind. This is an AI-assisted assessment submitted through the author's connected account, not independent human approval or a bypass of repository policy.
ACK for the implemented TLS/failover verification and the scoped fixes. HOLD merge/release approval until final-candidate checks pass.
Evidence inspected
- TLS run 35753025597, head
e455a857: twelve individual passing results, zero failures/skips/pending/other. Inspected artifact SHA256be97a5f32a3f79e431c1765466d1395e9a546bb5b52dd2af5aa413aeef0a3fddmatches GitHub metadata. Recorded merge revision:2d17f6f73dd085477805b507fd213fc2acf24e4c. - Actual publisher endpoint switch 41387 → 36183 and subscriber endpoint switch 40867 → 42441 are preserved in the trace. Each case retained an identified pending message during a complete path outage and received it after recovery, followed by a new post-recovery message. Zero duplicates were observed in those cases. Four live IPv4/IPv6 custom-port cases also passed.
- Full non-TLS run 35753021148, head
e455a857: 266 records, 261 passed, five failed, zero skipped. The repaired unacknowledged-message redelivery test passed. All five failures were inherited priority cases rejected for the quorumx-max-priorityargument.
Findings addressed in the current candidate
- Typed MaxPriority no longer sends the classic-only argument for explicitly configured quorum queues; classic configuration is retained.
- Priority tests now provision/bind through the provider before publishing, verify the full backlog and absence of consumers, and assert the received ID sequence. Four builder/direct × classic/quorum cases were added. Older-broker cases test their supported normal/high contract rather than assuming strict ordering within the high tier.
- RabbitMQ.Client 7.2.2's omitted-zero priority behavior is documented and explicitly represented in the expected results; it is not mislabeled as transmitting priority zero.
- A diff audit restored unrelated persistence-test behavior accidentally changed while replacing the priority test. The final delta does not alter that persistence method.
- Full verification now requires at least 270 individually passing non-TLS cases, including the four added priority cases. TLS remains a separate twelve-case required execution. No failing broker case was excluded or converted to a skip.
- README, runbook, and API comments distinguish implemented behavior, executed evidence, client limitations, and remaining broader #99 work.
Remaining acceptance
Current-candidate integration, TLS, endpoint, and Build checks were queued at this assessment. The priority fixes have not yet earned a completed final-candidate passing report. Earlier TLS passes are not substituted for that final execution.
The relay tests prove endpoint-path recovery with shared broker state, not replicated-queue survival after broker-node failure, rolling-upgrade availability, or process-crash durability. They do not justify closing the broader reliability issue. .NET 8 compilation is not .NET 8 runtime-test evidence.
Disposition: reviewer assessment and live failover coverage are recorded; full-integration acceptance remains open. Keep draft until completed final-candidate evidence supports approval.
niemyjski
left a comment
niemyjski
left a comment
There was a problem hiding this comment.
Final AI-assisted audit — September 22, 2026
Disposition: the previous final-execution hold is cleared for this PR's scoped endpoint, quorum-priority, and verification changes. Ready for maintainer review and merge consideration, subject to repository review requirements and the deployment limitations below. This supersedes the incomplete-CI disposition in reviews 5280440402 and 5281111347; it does not erase their historical evidence.
Reviewed head 3a31afd927a1eec1e52b6788998b344dca730409 against main aa062848eafaa04d8d1309f382b823f67bd68c41: 38 commits, 18 changed files, zero commits behind. The tested merge revision 16b76809304777cd7486453c655e0c50a41b882c has no file differences from the reviewed head. No additional blocking regression was identified in the scoped changes. No source changes were made during this final audit, so the reviewed candidate remains the candidate that passed CI.
Completed final-candidate evidence
- Strict integration 35756751384: 270 executed, 270 passed, 0 failed/skipped/pending/other. All 270 individual records are present, unique by name, and passed. All four new builder/direct × classic/quorum priority cases, five inherited priority cases, and the repaired unacknowledged-redelivery regression passed.
- TLS 35756751439: 12 executed, 12 passed, 0 failed/skipped/pending/other. All individual records passed, including both established-session recovery cases, four IPv4/IPv6 custom-port cases, positive provider traffic, and distinct certificate-name/chain rejection cases.
- Endpoint 35756751187: 37 executed, 37 passed, 0 failed/skipped/pending/other; all individual records verified. These 37 are a subset of the integration selection, not additional unique cases.
- Normal Build 35756752446: success. Provider builds for net8.0 and net10.0. Native MTP run reports 282 discovered, 270 succeeded, 0 failed, 12 explicit TLS exclusions; the separate TLS job executes those twelve. Build has one existing ASPIRE010 warning and zero errors. PR packaging/publishing stages were skipped, not tested.
The union of strict integration and TLS contains 282 distinct passing cases, with no overlap between those two reports. This is not a claim that every possible failure scenario has been covered.
Downloaded archive SHA256 values match GitHub artifact metadata:
- Integration artifact 10707804590:
af7a736b44e0447569be66084977ecc894231680e54538285bc49919e640a7f4. - TLS artifact 10708518899:
55ea26fce5004857357c5acadb5162e5c09fa45aba0fa349181df162154e12af. - Endpoint artifact 10709421571:
53f8435f0398d3e79609e26813d7693fbb9c216983040bf1f17eae76932ef368.
Final TLS trace records publisher endpoint 33431 → 38953 and subscriber endpoint 44619 → 33973. Each case observes both paths unavailable, one retained pending message, actual pending and post-recovery ID receipt, and zero observed duplicate deliveries. Both listener reports show AMQP over TLS and no plaintext AMQP listener. The inspected TLS/integration archives contain no private-key files or PEM private-key blocks; this limited inspection is not a comprehensive secret or dependency vulnerability scan.
Audit coverage and accepted boundaries
Re-read the changed implementation, call sites, endpoint parser and strict TLS policy, option/API documentation, fixture policy and seed startup, all new regression classes, modified inherited priority/redelivery cases, workflow selections/result gates, README, runbook, and existing PR reviews. Checked publication topology exists before priority assertions and that the persistence test was not accidentally changed. Existing acknowledgement, retry, recovery, Feedz/NuGet publishing policy, and production configuration were not changed by this audit.
The relay tests prove established endpoint-path recovery against shared broker state, not broker-node loss, replicated-queue availability, or crash durability. The replacement redelivery test verifies broker-unacknowledged messages reaching a provider subscriber; it does not verify forced termination of a blocked provider callback. Legacy chaos tests still do not provide complete loss-free-delivery proof; F11 remains only partially addressed.
Additional production/dependency qualification
The recorded test environment uses primary RabbitMQ 4.3.6, delayed-plugin RabbitMQ 4.2.5, chaos RabbitMQ 4.2.2, and TLS-only RabbitMQ 4.2.0. The older 4.2 fixtures are not approved production versions. A current advisory check found them within published rabbitmq-server affected ranges, including GHSA-5cq3-v9jx-p3x3 and GHSA-w9hf-476r-443x; later advisories require further patches. These are broker-server findings, not a finding that RabbitMQ.Client 7.2.2 is affected. Do not copy legacy fixture tags into production. Refresh and reverify test images in the broker-upgrade work, preserving delayed-plugin compatibility and never dropping tests to obtain green CI. Current release/support information lists 4.3.6; the 4.2 line has left community support. This review did not inspect any deployed broker or establish exploitation.
Broader required-delivery risks remain open in #99: acknowledgement after failed classic retry publication, broadcast retries, terminal/dead-letter outcomes, channel-only/consumer lifecycle recovery, dispatch outcomes, and in-memory delayed scheduling. This PR does not certify a no-loss required-event contract. Actual endpoint certificates, a patched supported production broker, and workload-specific rollout verification remain deployment prerequisites. Linux/.NET 10 execution is established; .NET 8 compilation is not .NET 8 runtime verification. No exhaustive vulnerability scan, release-package smoke test, production capacity test, or production deployment is claimed.
This is an AI-assisted review submitted through the author's connected account, not an independent human approval or a bypass of branch protection. No merge, release tag, or production deployment was performed. Keep #99 open.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
niemyjski
changed the title
niemyjski
changed the title
niemyjski
left a comment
niemyjski
left a comment
There was a problem hiding this comment.
AI-assisted reviewer ACK — 4.2.5 and consolidated verification
Reviewed candidate 7c1d47778779cbebd111efe0a6686721488c618d, including delivery/terminal handoffs, required dispatch, lifecycle generation isolation, broker-delay behavior, option validation/documentation, pinned broker declarations, shared fixture ownership, and the removal of the added verification workflows. This review is submitted through the author's connected account; it is not independent human approval or a bypass of repository requirements.
Verification: the existing Build 35797696327 checked out this exact SHA, built both provider target frameworks, and ran the normal complete test selection: 321 passed, 0 failed, 0 skipped. I inspected its completed job log. The preceding implementation/test commit 606e9bc also passed 321/321. The final difference is documentation only, but the final head was itself rebuilt and tested. There are no longer separately excluded TLS cases or four additional verification workflows.
Requested corrections verified
- Every repository-managed broker declaration is 4.2.5-management; live version assertions reject drift. The delayed plugin's independently versioned artifact remains 4.2.0. No 4.3 upgrade is included.
- Existing provider contract inheritance is preserved. Focused tests use
TestWithLoggingBase, inherited cancellation, and the logger factory. A single collection owns Aspire and temporary current-user TLS trust; fast configuration tests do not require the broker fixture. - Definite/ambiguous handoff failure retains the original while its subscriber remains ACK-capable. Real accepted publication followed by injected caller failure demonstrates the duplicate-safe identity boundary. It is not mislabeled as packet-level fault injection.
- Classic retries are subscription-local. Missing/unbound/full terminal destinations retain and resume after repair; explicit discard is separately tested. The broker's own quorum at-least-once terminal worker is tested independently from the provider terminal publisher.
- Channel-only closure, consumer cancellation, failed registration rollback, late handler completion, and uncooperative handlers are exercised without substituting a broker restart for each failure class.
- Required typed dispatch and required broker delay reject silent success/fallback. A real publisher process is killed after confirmed scheduling and before the due time; later receipt must preserve its ID.
- Prefetch assertions include broker backlog and complete drain. Rolling restart reconciles confirmed publication IDs instead of permitting percentage loss.
Compatibility and limits retained in the review
Exhausted messages now remain retained by default; absent a terminal route, this can deliberately block progress. Strict dispatch/routing/delay are opt-ins, and required deployment needs explicit durable topology, correct quorum broker-budget/DLX policy, and idempotent handlers. Source ACK and replacement publish cannot be atomic; duplicates remain possible. The plugin is single-node scheduling, not a replicated outbox. Unsafe broker TTL/overflow/deletion or permanent storage loss is not prevented by these client changes.
The final Build has one existing ASPIRE010 warning and no compilation errors. Broker tests run on .NET 10/Linux; .NET 8 compilation is not its own broker-runtime matrix. PR packaging/publishing stages were skipped; application deployment, broker security approval, and final package release are not asserted. The 4.2.5 compatibility requirement has not been replaced with an unauthorized upgrade.
Disposition: ACK for the implemented and tested provider contracts and requested test/workflow cleanup; ready for maintainer review/merge consideration with the documented compatibility changes. No additional blocking regression was identified in this review. This is not a proof of no undiscovered bugs or completion of every operational/performance item in #99. No merge or deployment is performed by this review.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c1d477787
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| var registration = cancellationToken.Register(() => | ||
| { | ||
| _subscribers.TryRemove(subscriber.Id, out _); | ||
| if (_subscriberRegistrations.TryRemove(subscriber.Id, out var current)) | ||
| current.Unregister(); |
There was a problem hiding this comment.
When the last subscription token is cancelled, this callback removes only the local handler and leaves the broker consumer running until the one-second maintenance poll. With the default FireAndForget strategy, RabbitMQ auto-acknowledges messages delivered during that interval, while OnMessageAsync waits because _subscribers is empty; channel cleanup then cancels those callbacks, permanently losing the messages. Stop the consumer when removal makes the subscriber collection empty rather than relying solely on periodic maintenance.
AGENTS.md reference: AGENTS.md:L3-L3
Useful? React with 👍 / 👎.
| _permanentSubscriberFault = false; | ||
| // Registration and setup share one failure boundary. The base's subsequent | ||
| // EnsureTopicSubscriptionAsync call is a no-op, so a failed setup cannot leak a handler. | ||
| await InitializeSubscriptionAsync(DisposedCancellationToken).AnyContext(); |
There was a problem hiding this comment.
If the caller cancels while connection or topology initialization is in progress, passing only DisposedCancellationToken prevents that cancellation from interrupting the setup, so SubscribeAsync can remain blocked until the internal 30-second timeout. If setup succeeds after cancellation, it can also create a consumer before the following cancellation check throws; on the first subscription the maintenance task has not started yet, leaving that consumer active without a handler. The setup path needs to observe the caller token and clean up any transport created after its registration is cancelled.
AGENTS.md reference: AGENTS.md:L72-L72
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c569775c14
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| catch (OperationCanceledException exception) | ||
| { | ||
| // A handler's own cancellation is not evidence of a successful side effect. | ||
| await RetainDeliveryAsync(exception, token).AnyContext(); |
There was a problem hiding this comment.
When a handler throws OperationCanceledException from its own timeout while the transport token remains active, this enters an infinite retention wait before checking the acknowledgement strategy. With the default FireAndForget strategy the broker has already acknowledged the message, so nothing is retained, while RabbitMQ.Client's default single-dispatch consumer remains stuck and cannot process subsequent messages; with automatic acknowledgements this also bypasses the configured retry/terminal path. Record this as failure and let the normal strategy-specific settlement execute.
AGENTS.md reference: AGENTS.md:L291-L292
Useful? React with 👍 / 👎.
| if (_builder is not null) | ||
| await _builder.DisposeAsync(); |
There was a problem hiding this comment.
At fixture teardown—and on partially successful startup failures—only the testing builder is disposed, while the separately built and started _app is dropped without calling DisposeAsync. The DistributedApplication owns the running test resources, so this can leave its RabbitMQ containers/processes alive and then attempt to delete certificate files that they still have mounted; dispose _app before the builder and certificate cleanup.
AGENTS.md reference: AGENTS.md:L71-L71
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in e25c4cf3cc5f96f80c79bd0af2156ae2fcede862. The collection fixture now disposes the built DistributedApplication first, then the testing builder, and finally its certificate resources, using nested finally blocks so later cleanup still runs if an earlier disposal fails. Owned references/status are cleared for repeated disposal and partial-startup cleanup. The existing Build 35810122479 checked out that exact revision and executed 321 tests: 321 passed, 0 failed, 0 skipped. This uses the existing shared fixture and workflow; no additional workflow or process-cleanup guard was introduced.
Test-convention follow-upThe naming/source-grouping, shared-priority-base, and fixture-ownership changes are pushed as separate commits Standalone added tests use the repository's operation/state/outcome naming with Async suffixes, related cases are grouped in source, and helpers follow test cases. Inherited Foundatio contract names are preserved; no execution-order dependency or custom test orderer was introduced. Configuration-only guards are outside the Aspire collection. The shared priority fact now uses the virtual provider factory so classic subclasses do not accidentally test quorum configuration, and the reusable priority verifier lives in the existing shared base rather than a concrete test class. Fixture teardown explicitly disposes the built application before the builder and certificate resources. Current review hold: while reading the existing review feedback I confirmed a strict-dispatch handler-local cancellation path that bypasses normal retry/terminal handling, plus a cancelled-initialization lifecycle gap. Commit |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 89811a5824
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| { | ||
| if (!String.IsNullOrWhiteSpace(_options.DeadLetterExchange)) | ||
| { | ||
| var properties = CopyHandoffProperties(envelope); |
There was a problem hiding this comment.
When an exhausted delivery carries an AMQP UserId set by a producer using different RabbitMQ credentials, CopyHandoffProperties retains that producer identity for the newly added client-side terminal publish. RabbitMQ validates UserId against the authenticated handoff connection, so the publish closes/fails the channel and TransferAndAcknowledgeAsync retries forever, leaving the original delivery blocked instead of reaching the configured dead-letter destination. Clear UserId before republishing, or preserve it in a non-validated metadata header.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 084679cef8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| var properties = new BasicProperties(envelope.BasicProperties) | ||
| { | ||
| Headers = new Dictionary<string, object?>(envelope.BasicProperties.Headers ?? new Dictionary<string, object?>()) | ||
| }; | ||
| properties.Headers.Remove("x-delay"); |
There was a problem hiding this comment.
When a received delivery carries RabbitMQ's CC sender-selected-routing header, this copy preserves it for both classic retry and terminal handoff publications. RabbitMQ will route the handoff using both the method's explicit routing key and the externally supplied CC keys, so a failed message can be duplicated into unrelated queues instead of remaining subscription-local or confined to its terminal destination. Remove CC and other routing-control headers before republishing.
AGENTS.md reference: AGENTS.md:L166-L168
Useful? React with 👍 / 👎.
niemyjski
changed the title
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9c3b3b1c03
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| var factory = new ConnectionFactory { Uri = new Uri(connectionString) }; | ||
| await using var connection = await factory.CreateConnectionAsync(setup.Token); |
There was a problem hiding this comment.
When --provision-quarantine is combined with --hosts, this setup connection uses only the endpoint embedded in connectionString, whereas the message buses below receive hostsList. If that primary endpoint is unavailable but a replacement host is healthy, the subscriber exits during provisioning before its configured failover can take effect. Provision the quarantine topology through the same resolved endpoint list and TLS policy as the message bus.
AGENTS.md reference: AGENTS.md:L288-L292
Useful? React with 👍 / 👎.
niemyjski
changed the title
💡 Codex Review Preserve custom TLS settings when cloning endpoints
When callers pass a ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
7d01c8b to
5899502
Compare
5899502 to
f153dac
Compare
f153dac to
f3544f5
Compare
f3544f5 to
3144246
Compare
3144246 to
3f7ede0
Compare
3f7ede0 to
7bc804a
Compare
7bc804a to
5b69ee9
Compare
niemyjski
changed the title
5b69ee9 to
c44286a
Compare
c44286a to
abba355
Compare
abba355 to
ed8606b
Compare
1 participant
The Aspire sample demonstrates classic and quorum delivery safety with separate subscribers, quarantine destinations, deliberate handler failures, and recovery controls. The README explains queue migration and the priority-ordering changes when upgrading to RabbitMQ 4.3, alongside the companion Foundatio guide.
Sample behavior change: the demonstration enables confirmed routing and required dispatch, provisions quarantine, and limits ready messages to 16 MiB per queue with reject-publish overflow. These are sample settings, not new library defaults. Existing classic queues cannot become quorum queues in place; use new queue names and migrate.
Inherited breaking changes: #106 rejects classic priority limits on quorum queues. #105 retains exhausted Automatic deliveries without a terminal destination, which can stop consumption and grow backlog. Both modes support confirmed terminal transfer; replication and broker-managed at-least-once dead-lettering require quorum queues. Ready-message limits do not cap unacknowledged work or total broker storage.
Broker upgrade impact: quorum priorities 5 and 10 change from one high-priority group to distinct strict priorities in 4.3. Lower-priority traffic loses its guaranteed share and may starve. An omitted priority defaults to 4, including zero omitted by RabbitMQ.Client 7.2.2. Classic scheduling and already-delivered messages retain their behavior in the tested scenarios.
Validation: Release build and formatting passed. Nine new priority/routing cases passed without skips on 3.13.7, 4.2.5, and 4.3.6 at the aggregate revision. All updated-head Linux checks passed. The push run passed 391 tests with five expected strict-quorum version skips. Companion docs PR #574 pins this aggregate and passed its updated-head build, link/example checks, and both CI checks. The full broker/TLS suite targets 4.2.5; CI also runs dedicated 4.3.6 priority/routing tests.
Verification and implementation details
The version matrix compares fresh brokers. A rolling upgrade with existing queue data was not exercised.
The subscriber accepts a queue type, explicit terminal destination, optional quarantine provisioning, and failure injection. Provisioning uses the same validated replacement endpoints as the bus. Invalid queue types, acknowledgement modes, and required-processing combinations fail before startup. Connection credentials are no longer written to logs. A separate process-level sample test checks replacement-host provisioning.
Failed sample publication is logged; there is no durable outbox. Before RabbitMQ 4.3, initial scheduling can use the archived delayed-exchange plugin; the default in-memory fallback loses pending work when the publisher exits. Native 4.3+ quorum delayed retries apply to returned deliveries, not initial scheduling. Priority-only 4.3 coverage does not validate every newer-broker feature.
This latest update rebases the sample onto independent compatibility tests and updates README upgrade guidance. It adds no library runtime changes or further edits to existing test methods. The exact untouched pre-PR priority test fails on both 4.2.5 and 4.3.6 because it combines quorum with classic
x-max-priority; its earlier green CI had skipped it. New tests exercise valid classic and quorum configurations separately.Merge after #105. Coordinate companion documentation with the provider release because these APIs are not released yet.