-
Notifications
You must be signed in to change notification settings - Fork 0
⭐ EventBusRabbitMQ
Terrence Daniels edited this page Aug 15, 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 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.