Skip to content

⭐ EventBusRabbitMQ

Terrence Daniels edited this page Aug 18, 2026 · 2 revisions

Done. All 6 source files added and reviewed — the most significant review pass so far, turning up two real bugs in upstream Microsoft source, not local mistakes.

  • A null-conditional (_rabbitMQConnection?.CreateChannelAsync()) that looked like it handled a closed connection gracefully, but actually short-circuited to a null Task, making its ?? throw fallback unreachable dead code — a caller during startup would get an opaque NullReferenceException instead of the intended error message.
  • The Polly retry pipeline ran publish through the synchronous Execute<TResult> overload on an async lambda — confirmed by reflecting the real Polly.Core 8.6.6 assembly, not assumed. Any exception thrown after the lambda's first await happened after Execute had already returned, so the retry logic never observed the exact failures (BrokerUnreachableException, etc.) it was configured to catch.

Both bugs lived in one class doing too much — RabbitMQEventBus mixed transport plumbing with OpenTelemetry tracing and Polly resilience. Fixed with a Decorator split: IEventBus is now implemented three times (bare RabbitMQEventBus → wrapped by TelemetryEventBusDecorator → wrapped by ResilientEventBusDecorator, now using the correct ExecuteAsync). See docs/architecturedesign.md Section 8 — this became the template for the rest of the build, not a one-off.

Test coverage complete too: tests/EventBusRabbitMQ.UnitTests, 17 passing tests. The Decorator split paid off here directly — ResilientEventBusDecoratorTests.cs verified the Polly retry fix end-to-end for the first time, against a fake inner IEventBus, since no real broker exists yet to prove it. See Testing.

Clone this wiki locally