[docs] test

[aspire-repo-bot]

test

Generated by PR Documentation Check for issue #17148 · ● 43.1M · ◷

[Copilot]

Pull request overview

Adds documentation to the RabbitMQ AppHost integration page explaining RabbitMQ 4.3’s stricter queue declaration rules (non-durable + non-exclusive queues being rejected) and how this impacts Aspire users when using the default RabbitMQ container image.

Changes:

• Document RabbitMQ 4.3 queue declaration restriction and resulting broker error.
• Provide alternative supported queue declaration patterns (durable, transient exclusive, durable + TTL).
• Add a note clarifying that queue topology is managed by application code, not the Aspire integration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[IEvangelist]

Generated by running the doc-tester skill against this PR (local
docs site started with aspire start --isolated, page rendered and
validated via Playwright, external link verified, surrounding pages
cross-referenced for consistency).

Summary

The new "RabbitMQ 4.3 queue declaration requirements" section in
src/frontend/src/content/docs/integrations/messaging/rabbitmq/rabbitmq-host.mdx
is a useful and timely addition — RabbitMQ 4.3.0 does deny
transient_nonexcl_queues by default, and the prescribed remediation
(durable / transient‑exclusive / durable + queue TTL) matches the
upstream release notes.

However, the closing <Aside type="note"> contains two factual
inaccuracies about the Aspire integrations themselves that should be
fixed before this merges. The PR title ([docs] test) also doesn't
describe the change.

Verdict: Request changes — small, surgical edits to the Aside (and a
real PR title) and this is good to go.

Findings

🔴 Blocker — IBus is not registered by Aspire.RabbitMQ.Client

Location: rabbitmq-host.mdx, new <Aside type="note"> block
(line 391):

The Aspire RabbitMQ integrations — Aspire.Hosting.RabbitMQ and
Aspire.RabbitMQ.Client — only register the connection
(IConnection/IBus) and provide DI, configuration, telemetry,
and health checks.

IBus is the top-level abstraction from
EasyNetQ, a third‑party
RabbitMQ.NET library that is not part of Aspire. Aspire's client
integration registers an IConnection from RabbitMQ.Client — and
nothing else — as the sibling page makes explicit:

"It registers an IConnection
through dependency injection and adds health checks and telemetry
automatically."
— rabbitmq-connect.mdx, line 52

IBus is also not referenced anywhere else in the docs site (verified
via grep across src/frontend/src/content/docs). Leaving the mention in
will mislead readers into expecting IBus from the DI container.

Suggested wording: drop IBus entirely — just IConnection.

🔴 Blocker — Conflates the hosting integration with the client integration

Same Aside, same sentence. It says both Aspire.Hosting.RabbitMQ and
Aspire.RabbitMQ.Client "only register the connection (IConnection)
and provide DI, configuration, telemetry, and health checks." That's
wrong for the hosting integration:

• Aspire.Hosting.RabbitMQ runs RabbitMQ as an AppHost resource and
  exposes a connection string + endpoints to consumers. It runs inside
  the AppHost process, not in the consuming application, and does not
  register IConnection in any DI container. The rest of this same
  page makes that clear (resource modelling, AddRabbitMQ, AsExisting,
  hosting health check via AspNetCore.HealthChecks.Rabbitmq).
• Aspire.RabbitMQ.Client is the consumer‑side integration that
  registers IConnection, telemetry, health checks, etc.

The Aside's point — "queue topology is owned by your app code, not by
the Aspire integrations" — is the valuable bit and worth keeping.

Suggested wording (illustrative):

<Aside type="note">
  Neither the Aspire RabbitMQ hosting integration
  (`Aspire.Hosting.RabbitMQ`) nor the client integration
  (`Aspire.RabbitMQ.Client`) declares queues for you. The hosting
  integration models and runs the RabbitMQ broker as a resource and
  exposes a connection string; the client integration registers an
  `IConnection` and wires up DI, configuration, telemetry, and health
  checks. Queue topology is entirely owned by your application code, so
  any queue declarations your app makes must comply with the RabbitMQ
  4.3 requirements above.
</Aside>

🟡 Major — "Starting with Aspire 13.4, the default RabbitMQ container image is 4.3" is not documented in the 13.4 release notes

Location: rabbitmq-host.mdx line 380 (first sentence of the new
section).

The PR adds a hard claim that pins behavior to a specific Aspire release
(13.4) and a specific broker image (4.3). Since the broker version bump
can break running apps (that's the whole point of the new section), it
would normally be called out in the matching What's New page. But
src/frontend/src/content/docs/whats-new/aspire-13-4.mdx doesn't
mention RabbitMQ, the 4.3 image, or this deprecation under either the
release highlights or the "Migration from Aspire 13.3 to 13.4" section.

Either:

• add a short bullet to aspire-13-4.mdx under
  "Migration from Aspire 13.3 to 13.4" that links to this new section,
  or
• rephrase the opening sentence here so it doesn't imply a 13.4
  release‑notes entry that doesn't exist (for example:
  "The default RabbitMQ container image used by AddRabbitMQ is
  RabbitMQ 4.3, which …").

This matters because a user who hits AMQP 541 after aspire update will
typically scan the release notes first, find nothing, and not know to
look on this integration page.

🟢 Minor — PR title is uninformative

The PR is titled "[docs] test" but the diff is a meaningful
documentation change. The bot‑authored commit message
("docs: document RabbitMQ 4.3 transient non‑exclusive queue
deprecation") is already a good title — please use it or a close
variant before merge. This was specifically flagged as part of the
review request.

🟢 Nit — Heading slug renders as rabbitmq-43-queue-declaration-requirements

Starlight drops the . from 4.3, so the table‑of‑contents anchor
becomes #rabbitmq-43-queue-declaration-requirements (verified in the
local render). Functional, but reads slightly as "RabbitMQ 43". You can
optionally make this explicit with a Starlight heading id, e.g.
## RabbitMQ 4.3 queue declaration requirements { #rabbitmq-4-3-queue-declaration-requirements },
to match the version that everyone is going to type. No blocker.

What I verified (evidence)

• Rendered the page locally against the worktree via
  aspire start --isolated → frontend at http://localhost:62318/ and
  navigated to
  /integrations/messaging/rabbitmq/rabbitmq-host/ (200 OK,
  <title>Set up RabbitMQ in the AppHost | Aspire</title>).
• Used Playwright to walk the DOM under
  #rabbitmq-43-queue-declaration-requirements and confirmed every
  paragraph, list item, and the <Aside> render with the expected text.
• Followed the external link
  https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.0 →
  resolves, and the "Deprecated Features are Now Disabled by Default"
  section explicitly lists transient_nonexcl_queues and recommends
  the same three alternatives the doc proposes (durable, transient
  exclusive, durable + queue TTL).
• Grepped src/frontend/src/content/docs/** for IBus and EasyNetQ
  — only the new Aside mentions IBus, and EasyNetQ is not in the
  docs at all. The neighbor page rabbitmq-connect.mdx is the canonical
  description of what the client integration registers, and it says
  only IConnection.
• Grepped src/frontend/src/content/docs/whats-new/aspire-13-4.mdx for
  rabbitmq / 4.3 — no hits.
• The intra‑integration relative link on line 376
  (../rabbitmq-connect/) is pre‑existing and not part of this diff,
  so out of scope here.

Knowledge gaps (per doc‑tester skill)

Knowledge Gap: IBus vs IConnection

• What I needed to know: That IBus is from EasyNetQ (third party)
  and is not what Aspire.RabbitMQ.Client registers.
• Source of my knowledge: Prior knowledge of the .NET RabbitMQ
  ecosystem + the existing wording on
  /integrations/messaging/rabbitmq/rabbitmq-connect/. The new Aside
  alone does not signal that IBus is anomalous.
• User impact: A reader new to Aspire and RabbitMQ would reasonably
  expect to be able to [FromServices] IBus bus in their consumer.
  They'll get a DI resolution error.
• Recommendation: Remove IBus from this Aside.

Knowledge Gap: Aspire 13.4 default RabbitMQ image bump

• What I needed to know: Whether the default image really is
  RabbitMQ 4.3 starting in 13.4.
• Source of my knowledge: Not the documentation — aspire-13-4.mdx
  doesn't say so, and the doc‑tester methodology says not to fall back
  to the Aspire product source.
• User impact: Anyone hitting AMQP 541 after upgrading to 13.4 will
  not find this from the release notes.
• Recommendation: Cross‑link from aspire-13-4.mdx
  ("Migration from Aspire 13.3 to 13.4" section) so users discover
  this page from where they actually look.