-
Notifications
You must be signed in to change notification settings - Fork 0
⭐ EventBusRabbitMQ
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 nullTask, making its?? throwfallback unreachable dead code — a caller during startup would get an opaqueNullReferenceExceptioninstead 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 realPolly.Core 8.6.6assembly, not assumed. Any exception thrown after the lambda's firstawaithappened afterExecutehad 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.