📦 Modernize `Orleans.Providers.RabbitMQ` for Orleans v8+ and RabbitMQ v7 Client

[SilentBlueD666]

📝 Introduction

This issue tracks the work to modernize the Orleans.Providers.RabbitMQ library, bringing it up to date with:

• The latest Orleans streaming provider design patterns (v8+)
• The RabbitMQ .NET Client v7.x .NET/C# RabbitMQ Client Library

The goal is to make the provider reliable, extensible, and production-ready — aligning with Orleans' dependency injection and lifecycle models, improving throughput and resiliency, and embracing modern RabbitMQ features.

Given the age and structure of the current library, we will rebuild the provider from the ground up rather than modify the existing codebase.

👉 Community feedback is welcome and encouraged, if you have ideas, use cases, or suggestions, please share them in this issue!

---

✅ Goals / Features for the New Version

⬆️ Upgrade to RabbitMQ.Client v7

• Adopt new APIs and handle breaking changes
• Improve connection lifecycle and error handling

🧱 Align with Orleans v8+ Streaming Provider Architecture

• Rename library to Orleans.Streaming.RabbitMQ
• Support proper lifecycle management via ILifecycleParticipant<ISiloLifecycle> and/or DI disposal patterns.

🧵 Improve Concurrency & Reliability

• Ensure thread-safe publishing and consuming

📈 Metrics & Observability

• Use high-performance structured logging (e.g., Microsoft.Extensions.Logging)
• Integrate with Orleans telemetry (OpenTelemetry-friendly)
• Expose key metrics: consumed messages, published messages, etc.

🧪 Testing (Unit + Integration)

• Provide mocked tests for core components
• Use Docker/Testcontainers for full RabbitMQ integration testing
• Cover edge cases: message loss, reconnects, pub-sub fanout

↩️ Backpressure & Retry Support

• Respect Orleans backpressure and flow control expectations
• Optional Provide configurable retry strategies
• Optional support for DLQ (dead letter queue) on failure

📤 Producer Enhancements (optional)

• Handle publisher confirms
• Support message properties (headers, content type, etc.)

🔗 Explore RabbitMQ Stream Plugin (optional)

• Support for rewindable streams and high-throughput scenarios
• Consider using this as an alternative provider (e.g., Orleans.Streaming.RabbitMQ.Streams)

[galvesribeiro]

Thanks for the issue.

Can you get into more details on the plan for the implementation? It seems that you used some sort of AI to write it but I'd like to see what practical improvements you're looking to bring to the table with this "rebuild". Do you have a prototype and sketches on where would you take the improvements?

Optional support for DLQ (dead letter queue) on failure

For example, this is not a pattern that fit on Streaming. In particular Orleans messages for that matter.

Implement modern provider interfaces:

Those are implemented already otherwise, the provider wouldn't work at all.

So if you are using AI to propose something, I think it would be better to give it more context of what Orleans is, how the streaming works, and then propose improvements.

Also, lets refrain from use the RabbitMQ experimental features.

For the record - this provider was used in production for a long time already. It just got outdated compared with current Orleans and RabbitMQ versions. I stopped using it when we ditched RabbitMQ in favor of NATS for our backend messaging infrastructure.

[SilentBlueD666]

Hi,

I did use AI to write the issue, however not the code. I have a proto type that will put in the root folder of my fork, let's keep simple and say prototype.

Now I have re-read the post, I can easily see how it's missing a lot of context, sorry 😬

Continuing on this example:

Implement modern provider interfaces:

What I really meant was use the new types used in the interfaces i.e. Guid streamGuid now changed to StreamId streamId

I think I saw the op as a brain dump of what I been looking at and where I wanted to go, on review requires a lot rework, a work in progress shall we say 😁

[galvesribeiro]

All good.

Just pointed out because writing a stream provider from the ground up is a considerable amount of work. Specially for a provider using a queue backend which has proven to be challenging to deal with (trust me, I've done many).

That being said, feel free to work on your fork but as Reuben said before on Discord, make sure to keep the existing tests and add new ones which makes sense for the new implementation if needed.

No one is resistant to get a refresh on this provider as it is long overdue but if we're gonna do it lets do it correctly :)

Looking forward to see what you come up with.

[SilentBlueD666]

OK, pushed my first draft, only been playing with it after work for a few weeks, so easy on the judging 😅 but I think it's a good starting point.

https://github.com/SilentBlueD666/Orleans.Providers.RabbitMQ/tree/v7-upgrade/prototype

[SilentBlueD666]

Hi Guys,

Just wondering if you had a chance to look at the prototype yet? Would love to get this wrapped up 😁 Let me know what you think the next steps are.