Brighter V10 Release Candidate 2 - What is new?

In the previous article, I discussed Brighter V10 RC 1 and its significant updates. Just recently (August 10, 2025), the Brighter team has released Release Candidate 2, bringing additional features, important bug fixes, and refinements to the framework. This article explores what's new in Brighter V10 RC2 and how these changes can benefit your applications.

New Features and Enhancements

While Brighter V10 RC2 introduces a few more changes, the team has confirmed that no further breaking changes are planned for the final release. This RC2 focuses on feature completion and stability improvements.

Support to AWS SDK v4

Brighter V10 RC2 now officially supports AWS SDK v4 while maintaining compatibility with SDK v3. This dual-support approach is particularly valuable for enterprise environments where large-scale package upgrades can be complex and time-consuming. Many organizations have indirect dependencies on AWS SDK v3 through other libraries and may need to coordinate migrations across multiple projects.

In a future article, I'll demonstrate practical implementation examples for both SDK versions.

Official RocketMQ Integration

Brighter V10 RC2 now includes official support for RocketMQ, a distributed messaging and streaming platform originally developed by Alibaba and now maintained as an Apache project. RocketMQ is designed for high-throughput, low-latency messaging with strong durability guarantees, making it ideal for mission-critical applications requiring reliable message delivery at scale.

This integration expands Brighter's messaging ecosystem, giving developers another powerful option for building resilient, distributed systems. I'll provide detailed usage examples in an upcoming article.

Quorum Queues Support for RabbitMQ

RC2 adds full support for RabbitMQ's Quorum Queues, which represent a significant advancement over the traditional classic queues. Quorum Queues use the Raft consensus algorithm to replicate messages across nodes, ensuring data safety and high availability. Unlike classic mirrored queues, Quorum Queues provide consistent message ordering, automatic leader election during node failures, and better resource utilization.

This feature is particularly valuable for applications requiring strong durability guarantees where message loss cannot be tolerated, such as financial transactions or critical business processes.

UUID v7 for Message IDs

Starting with RC2, Brighter now uses UUID v7 as the default for message identifiers when running on .NET 9+. UUID v7 incorporates timestamps into the UUID structure, making identifiers roughly time-ordered while maintaining global uniqueness.

This change provides significant performance benefits for inbox and outbox patterns, especially when using these IDs as database keys. Time-ordered UUIDs reduce page splits and fragmentation in indexed databases, leading to better write performance and more efficient storage utilization.

Developers should now use:

public class SomeCommand() : Command(Id.Random());

// or
public class SomeCommand() : Command(Uuid.New());

Resilience Pipeline Integration

Polly v8 introduced the powerful Resilience Pipeline concept, and Brighter V10 RC2 now fully embraces this pattern. We've replaced all internal usage of the older Policy pattern with the more flexible and performant ResiliencePipeline approach.

The Resilience Pipeline allows combining multiple resilience strategies (such as retry, timeout, and circuit breaker) into a cohesive execution pipeline. This provides better performance through reduced exception throwing (using the Outcome pattern), more efficient context sharing between strategies, and improved memory allocation characteristics.

As shown in the Polly documentation, Resilience Pipelines enable sophisticated patterns like nested timeout strategies with retry logic, providing precise control over failure handling in distributed systems.

Dynamic Partition Key and Header Management

In Brighter V10 RC1, setting partition keys and message headers dynamically wasn't possible with default mappers. RC2 resolves this limitation through the RequestContext object, giving developers fine-grained control over message routing and metadata.

processor.Post(new SomeRequest(), new RequestContext 
{
   Bag = 
   {
       [RequestContextBagNames.PartitionKey] = "some-partition",
       [RequestContextBagNames.Header] = new Dictionary<string, object>
       { ["some-header"] = "some-value" }
   }
})

This enhancement enables more sophisticated message routing strategies and integration with systems that require specific header values for processing.

Circuit Breaker for Outbox Pattern

RC2 introduces circuit breaker functionality for the outbox pattern, addressing a critical reliability concern. Previously, when a destination topic or queue was unavailable (due to infrastructure issues), Brighter would repeatedly attempt to deliver messages, potentially overwhelming the system.

The new circuit breaker implementation detects persistent failures and temporarily stops delivery attempts to problematic destinations. After a configured cooldown period, it will cautiously resume delivery attempts. This prevents wasted resources on doomed operations and allows the system to recover gracefully from transient infrastructure issues.

Bug Fixes

Several important bugs identified in RC1 have been addressed in this release

Consistent Random ID Generation

RC1 had an issue where Id.Random return the same value. This has been fixed in RC2 by moving from property to a method and enforce use different value each time.

Relational Database Outbox Improvements

A bug affecting message insertion into the relational database outbox has been resolved. The issue stemmed from how Brighter was storing URI values.

Outbox Swapper & Archive Registration

The registration process for the outbox swapper and archive components had issues that could prevent proper initialization. These have been fixed to ensure reliable startup and operation of these critical background services.

Graceful RabbitMQ Shutdown

One of the critical improvements in Brighter V10 RC2 addresses a significant reliability concern present in RC1: the inability to gracefully shut down RabbitMQ connections.

Conclusion

Brighter V10 RC2 represents a significant step toward the final release, delivering promised features while addressing critical issues discovered during RC1 testing. The addition of AWS SDK v4 support, RocketMQ integration, Quorum Queues for RabbitMQ, UUID v7 identifiers, Resilience Pipelines, and dynamic message routing capabilities substantially enhances Brighter's value proposition for building resilient distributed systems.

Based on the current stability and feature completeness, the Brighter team is targeting a final V10 release next month, assuming no major issues are discovered. Should significant problems emerge, a RC3 release would be prepared to address them before the final launch.

For developers considering Brighter for their next project or planning an upgrade from previous versions, RC2 brings the framework closer to its most robust and feature-complete state yet. The thoughtful migration path from V9, combined with the new capabilities in V10, makes this an exciting time to be working with the Brighter ecosystem.