dotnetcore/CAP

CAP is a .NET library that implements the Outbox pattern to ensure distributed transaction consistency between databases and message brokers. It supports a wide range of transports, including RabbitMQ, Kafka, Azure Service Bus, Amazon SQS, NATS, Redis Streams, and Pulsar, alongside various storage providers like SQL Server, MySQL, PostgreSQL, MongoDB, and Redis. The system provides a built-in dashboard for monitoring message status and metrics, with optional authentication and Kubernetes/Consul service discovery.

20 changes.

The project was rebranded from 'kafkabus' to 'CAP' and underwent a comprehensive architectural overhaul, replacing legacy consistency modules with a modular, pluggable processor pipeline. This period established the core distributed transaction API, refactored storage providers to leverage Entity Framework Core, and modernized transport implementations for RabbitMQ and Kafka with connection pooling and improved reliability.

18 changes.

This period focused on a major architectural refactoring of the CAP library, introducing new abstractions for persistence, transport, and messaging to support a modular design. It expanded storage capabilities by adding initial implementations for MongoDB, In-Memory, and enhanced Azure Service Bus, while simultaneously improving reliability through stricter transactional guarantees and observability via diagnostics and dashboard metrics.

15 changes.

This period focused on expanding CAP's transport capabilities by adding initial support for NATS JetStream, Amazon SQS, Apache Pulsar, and Redis Streams. Concurrently, the project modernized the dashboard by migrating its frontend from Razor to a Vue.js-based single-page application with internationalization and enhanced monitoring features.

7 changes.

This period focused on expanding observability with initial OpenTelemetry instrumentation and enhancing the dashboard with Chinese localization, charting, Kubernetes discovery, and JWT security. Significant work also went into the Azure Service Bus transport, introducing custom topic support, message sessions, and standardized address resolution, accompanied by comprehensive unit tests.

Introduces a new transport implementation for Apache Pulsar, allowing users to configure and use Pulsar as a message broker for CAP. This includes the \UsePulsar\ extension method for service registration, \PulsarOptions\ for configuring connection details and TLS settings, and the underlying transport logic for publishing and consuming messages via the Pulsar .NET client.

src/DotNetCore.CAP.Pulsar · high confidence

The dashboard now supports discovering and registering nodes via HashiCorp Consul. This change introduces a new \NodeDiscovery\ module containing configuration options (\ConsulDiscoveryOptions\), a provider implementation (\ConsulNodeDiscoveryProvider\) that queries the Consul catalog for CAP services, and a processing server that registers the current node with health checks. Users can enable this by calling \UseConsulDiscovery()\ on their CAP options, allowing the dashboard to dynamically locate other nodes in a Consul-managed environment.

src/DotNetCore.CAP.Dashboard/NodeDiscovery · high confidence

A new ValuesController has been added to the Sample.RabbitMQ.MongoDB project, demonstrating how to integrate MongoDB with RabbitMQ via CAP. The controller exposes endpoints for publishing messages without transactions, publishing delayed messages, and publishing messages within explicit MongoDB transactions (both auto-commit and manual commit modes). It also includes a subscriber endpoint to receive and log messages from the 'sample.rabbitmq.mongodb' topic.

samples/Sample.RabbitMQ.MongoDB/Controllers · high confidence

Introduces a new NATS JetStream transport for CAP, allowing users to configure NATS as the message broker via the \UseNATS\ extension method. This implementation supports configurable connection pooling, automatic stream and subject creation, concurrent subscriber execution, and custom header building, enabling reliable message delivery and consumption using NATS JetStream features.

src/DotNetCore.CAP.NATS · high confidence

Introduces a new sample project demonstrating how to integrate CAP with RabbitMQ for messaging and MySQL for persistence. The sample includes a minimal ASP.NET Core application setup with CAP services configured to use MySQL, RabbitMQ, and the built-in dashboard, along with corresponding logging configuration.

samples/Sample.RabbitMQ.MongoDB, samples/Sample.RabbitMQ.MySql · high confidence

The sample application now includes a ValuesController that demonstrates integration with RabbitMQ and MySQL. This controller exposes endpoints to manually start and stop the CAP background service, publish messages without transactions, publish delayed messages, and execute ADO.NET operations within a CAP-managed transaction. It also includes message subscribers for the corresponding topics.

samples/Sample.RabbitMQ.MySql/Controllers · high confidence

A new sample application has been added to demonstrate using CAP with a Redis cluster and SQL Server. The sample includes an ASP.NET Core controller that publishes messages to Redis and subscribes to them, configured via Program.cs to connect to a 6-node Redis cluster and a SQL Server database. A docker-compose.yml file is provided to spin up the required infrastructure (Redis cluster nodes and SQL Server) alongside the sample app for local testing.

samples/Samples.Redis.SqlServer · high confidence

A new \JsonUtf8Serializer\ class has been added to the serialization module, providing a concrete implementation of the \ISerializer\ interface that uses \System.Text.Json\ for message serialization and deserialization. This allows users to serialize and deserialize CAP messages using the modern System.Text.Json library instead of relying solely on other JSON libraries, with support for configurable \JsonSerializerOptions\.

src/DotNetCore.CAP/Serialization · high confidence

A new sample console application has been added to demonstrate how to subscribe to and publish events using the CAP library. The sample includes an EventSubscriber class that listens for the 'sample.console.showtime' event and a Program class that sets up an in-memory message queue and storage, registers the subscriber, and periodically publishes the current time. It also includes a custom subscribe filter to handle TimeoutExceptions during HTTP requests.

samples/Sample.ConsoleApp · high confidence

The CAP library now includes an internal ObjectMethodExecutor component that enables the dynamic execution of methods via reflection, with full support for asynchronous patterns. This addition allows the library to detect and await custom awaitable types, including F\# async workflows (FSharpAsync\<T\>), by coercing them into standard C\# awaitables at runtime without requiring a compile-time dependency on FSharp.Core. Users benefit from improved compatibility with diverse asynchronous method signatures and better performance when invoking methods dynamically, as the executor optimizes execution paths based on whether the return type is directly awaitable or requires coercion.

src/DotNetCore.CAP/Internal/ObjectMethodExecutor · high confidence

The core CAP library now exposes its foundational configuration and API surface, including the CapOptions class for tuning message expiration, retry policies, and parallel execution settings, alongside key interfaces like ICapPublisher for message publishing, ICapTransaction for outbox pattern coordination, and ICapSubscribe for subscriber discovery. The change also introduces the CapBuilder for fluent DI configuration, specific exception types such as BrokerConnectionException and SubscriberNotFoundException, and the CapHeader class to manage callback response headers, establishing the baseline API for the distributed messaging system.

src/DotNetCore.CAP · high confidence

The CAP Dashboard frontend has been replaced with a Vue.js application, introducing a new Home page with real-time and 24-hour history metric graphs, a Nodes page for Kubernetes service discovery and latency pinging, and updated Published and Received message pages that support delayed message filtering, re-execution, and deletion. The Subscriber page now displays detailed group, topic, and method implementation information, and the entire interface supports localization via i18n.

src/DotNetCore.CAP.Dashboard/wwwroot/src/pages · high confidence

The dashboard now supports Chinese language localization, with new translation files for English (en-us) and Chinese (zh-cn) providing labels for metrics, actions, and UI elements. Additionally, the static assets directory now includes the uPlot charting library (uPlot.esm.js and uPlot.min.css), enabling the rendering of real-time metric graphs and 24-hour history charts within the dashboard interface.

src/DotNetCore.CAP.Dashboard/wwwroot/src/assets · high confidence

The CAP dashboard now supports explicit anonymous access configuration via the new \AllowAnonymousExplicit\ option, allowing users to bypass authentication for the dashboard API when desired. Additionally, the dashboard now exposes real-time metrics (published and subscriber invocation rates) through a new \CapMetricsEventListener\ and corresponding API endpoints, providing users with live performance data directly in the dashboard interface.

src/DotNetCore.CAP.Dashboard · high confidence

This release introduces a new transport provider for Amazon SQS, enabling CAP to publish messages to AWS SNS topics and consume them from SQS queues. The implementation includes configuration options for AWS region, credentials, and custom service URLs (useful for local development), along with automatic topic creation and SQS access policy management. It supports concurrent message processing within consumer groups and handles message attributes and headers for reliable distributed messaging.

src/DotNetCore.CAP.AmazonSQS · high confidence

This change introduces the MongoDB persistence provider for the CAP distributed messaging system. It adds the necessary configuration options (connection string, database name, collection names), dependency injection registrations, and the core data storage implementation to handle publishing, receiving, and monitoring messages. It also includes a new transaction wrapper that integrates MongoDB client sessions with CAP's transaction management, allowing messages to be committed or rolled back atomically with database operations.

src/DotNetCore.CAP.MongoDB · high confidence

This change introduces the first OpenTelemetry support for CAP, adding a new \DotNetCore.CAP.OpenTelemetry\ package that enables distributed tracing for message publishing and consumption. Users can now call \AddCapInstrumentation()\ on their \TracerProviderBuilder\ to automatically capture activity spans for events like message persistence, publishing, and consumption, including context propagation via headers and standard semantic attributes (e.g., \messaging.system\, \server.address\).

src/DotNetCore.CAP.OpenTelemetry · high confidence

Adds a new in-memory storage provider for the CAP (Common Application Platform) library, enabling users to configure an ephemeral message store via the \UseInMemoryStorage\ extension method. This implementation registers the \InMemoryStorage\ service, which persists published and received messages in static \ConcurrentDictionary\ collections, and provides the necessary \ICapTransaction\, \IStorageInitializer\, and \IMonitoringApi\ interfaces to support message scheduling, retry logic, and dashboard statistics without requiring an external database.

src/DotNetCore.CAP.InMemoryStorage · high confidence

A new sample application (Sample.Dashboard.Jwt) is introduced that demonstrates how to secure the CAP dashboard with JWT authentication. It includes a login page (index.html) where users can enter credentials (default: bob/bob) to obtain a token via a /security/createToken endpoint, and the dashboard is then accessed using that token passed as a query parameter. The sample configures ASP.NET Core JWT Bearer authentication, validates tokens using a symmetric key, and runs as a standalone Docker container.

samples/Sample.Dashboard.Jwt · high confidence

The CAP Dashboard now supports discovering nodes via Kubernetes services. Users can enable this by calling \UseK8sDiscovery()\ on their CAP options, which registers the necessary discovery provider and allows the dashboard to list and monitor services running in a Kubernetes cluster. The feature includes configuration options to customize the Kubernetes client connection and control node visibility (e.g., showing only nodes with specific labels).

src/DotNetCore.CAP.Dashboard.K8s · high confidence

A new sample application has been added to the \samples/Sample.Kafka.PostgreSql\ location, demonstrating how to integrate Apache Kafka and PostgreSQL using the .NET minimal hosting model. The sample includes an \AppDbContext\ with a custom \CapNpgsqlRelationalConnection\ that synchronizes database commits and rollbacks with the DotNetCore.CAP distributed transaction manager, ensuring data consistency across the message broker and the database. The \Program.cs\ file configures the necessary services for CAP, PostgreSQL, and Kafka, providing a concrete example of this architecture for users.

samples/Sample.Kafka.PostgreSql · high confidence

The sample application now includes a ValuesController that showcases how to integrate Kafka message publishing with PostgreSQL storage using the CAP library. This controller provides endpoints for starting and stopping the bootstrapper, publishing delayed messages, and publishing messages both with and without database transactions. It specifically demonstrates transactional consistency by showing how to publish messages alongside ADO.NET (Npgsql) and Entity Framework Core database operations, ensuring that messages are only committed if the associated database transaction succeeds.

samples/Sample.Kafka.PostgreSql/Controllers · high confidence

The Diagnostics directory now contains the core components for CAP's observability layer. This includes CapDiagnosticListenerNames, which defines the event names for tracing publish, consume, and subscriber invoke operations, and CapEventCounterSource, which exposes runtime metrics such as publish/consume rates and subscriber invocation latency via .NET EventSource. Additionally, new data classes (CapEventDataPubStore, CapEventDataPubSend, CapEventDataSubStore, CapEventDataSubExecute) have been added to structure the payload for these diagnostic events, enabling users to integrate with external monitoring and tracing tools.

src/DotNetCore.CAP/Diagnostics · high confidence

Added a new sample project demonstrating how to use CAP with RabbitMQ for message transport and SQL Server for persistence. The sample includes a minimal hosting model setup, an Entity Framework Core context, and a controller showcasing various transactional patterns: standard publishing, delayed publishing, ADO.NET transactions, and Entity Framework Core transactions. It also introduces a typed consumer model using a custom \QueueHandler\ base class and \QueueHandlerTopicAttribute\ to route messages to specific handlers based on topics.

samples/Sample.RabbitMQ.SqlServer · high confidence

The project has been renamed from 'kafkabus' to 'CAP' (DotNetCore.CAP), a .NET library for distributed transactions and event bus integration. The repository now includes a fully rewritten English README and a new Chinese README (README.zh-cn.md) detailing the Outbox Pattern, supported transports (RabbitMQ, Kafka, Azure Service Bus, Amazon SQS, NATS, Redis Streams, Pulsar), and storage providers (SQL Server, MySQL, PostgreSQL, MongoDB). The solution structure has been reorganized into a new CAP.sln file, replacing the legacy Cap.sln, and includes a new Flubu build script (.flubu) and AppVeyor CI configuration (appveyor.yml) targeting .NET 10. Additionally, a Code of Conduct (code-of-conduct.md) has been added, and legacy files like .gitattributes have been removed.

(repo-wide) · high confidence

The Redis Streams transport for CAP has been implemented, introducing a new \UseRedis()\ extension method to configure the message broker. This change adds a dedicated connection pool (\RedisConnectionPool\) that manages \StackExchange.Redis\ multiplexers with configurable pool sizes and lazy initialization, improving resource efficiency. The consumer client (\RedisConsumerClient\) now supports concurrent message processing via a \GroupConcurrent\ option and includes a configurable \OnConsumeError\ callback to handle consumption failures gracefully. Additionally, the transport handles Redis cluster environments by grouping stream reads by hash slots and ensures robust stream/group creation logic to prevent race conditions during startup.

src/DotNetCore.CAP.RedisStreams · high confidence

The Sample.Dashboard.Auth sample now includes a complete ASP.NET Core application that configures the CAP dashboard with authentication. It provides three distinct configuration patterns: using OpenID Connect via Duende Software, using a custom authentication scheme (checking for a specific header), and combining both schemes under a single authorization policy. The sample also includes a ValuesController to demonstrate publishing and subscribing to CAP messages within an authenticated context.

samples/Sample.Dashboard.Auth · high confidence

The Azure Service Bus producer now allows configuring custom topic paths and enabling message sessions for individual producers. This is achieved through a new descriptor-based architecture where users can specify the target topic, control subscription creation, and enable session support via a builder pattern, providing finer control over how messages are routed and processed within Service Bus.

src/DotNetCore.CAP.AzureServiceBus/Producer · high confidence

The entire Cap.Consistency module has been removed, deleting the legacy Kafka consistency implementation and its associated infrastructure. This includes the removal of the old project file (Cap.Consistency.xproj) and dependency manifest (project.json), as well as all source code files that provided the message store abstraction (IConsistentMessageStore), message management (ConsistentMessageManager), service registration extensions (ServiceCollectionExtensions, BuilderExtensions), and result types (OperateResult).

src/Cap.Consistency · high confidence

The monitoring subsystem now exposes a new \IMonitoringApi\ interface along with supporting DTOs (\MessageDto\, \MessageQueryDto\, \StatisticsDto\, \PagedQueryResult\) to enable programmatic access to message statistics, individual message details, and paginated query results. This change introduces the contract for retrieving published/received message counts, hourly job statistics, and detailed message information, laying the groundwork for the dashboard API.

src/DotNetCore.CAP/Monitoring · high confidence

The persistence layer now exposes the \IDataStorage\ and \IStorageInitializer\ interfaces along with a \MediumMessage\ data model. \IDataStorage\ defines the contract for asynchronous operations including distributed locking, message state transitions (publish/receive), delayed message scheduling, and message deletion. \IStorageInitializer\ handles storage initialization and table name resolution, while \MediumMessage\ serves as the internal representation for messages stored in the database, tracking metadata such as retries, expiration, and content.

src/DotNetCore.CAP/Persistence · high confidence

The transport subsystem now uses a new set of interfaces and types to manage message broker connections and operations. A new \BrokerAddress\ struct encapsulates broker identification and network endpoints, supporting a combined string format for easier configuration. The \IConsumerClient\ interface defines the contract for subscribing to topics, listening for messages, and handling callbacks, while \IConsumerClientFactory\ allows for the creation of consumer instances with configurable concurrency limits. Additionally, \ITransport\ and \IDispatcher\ interfaces standardize message sending and scheduling, and a new \MqLogType\ enum along with \LogMessageEventArgs\ provides structured logging and event notification for broker health and errors.

src/DotNetCore.CAP/Transport · high confidence

The Azure Service Bus transport implementation has been rewritten to support new capabilities including message sessions, scheduled enqueue times, and configurable concurrent message processing. Users can now enable sessions via the \EnableSessions\ option, schedule messages for future delivery using the \ScheduledEnqueueTimeUtc\ header, and control concurrency with the \GroupConcurrent\ setting. The transport also introduces \AutoProvision\ for automatic topic/subscription creation, \SQLFilters\ for custom subscription rules, and \CustomHeadersBuilder\ for mapping additional message properties. These changes are part of a broader v3.0 architectural refactoring of the CAP Azure Service Bus integration.

src/DotNetCore.CAP.AzureServiceBus · high confidence

The CAP Dashboard's user interface has been rebuilt using the Vue.js framework, replacing the previous Razor-based implementation. This change introduces a modern single-page application structure with client-side routing, state management, and internationalization (supporting English and Chinese). Users will experience a refreshed UI layout with navigation and footer components, real-time metric polling, and JSON pretty-printing capabilities, all powered by the new Vue frontend assets.

src/DotNetCore.CAP.Dashboard/wwwroot/src · high confidence

The CAP Dashboard's user interface has been replaced with a Vue.js-based implementation, introducing a new navigation and footer structure. Users will now see a modernized layout featuring a sticky navigation bar with dynamic menu badges and a footer displaying system metadata (CAP version, storage, and transport details). A key addition is built-in internationalization, allowing users to switch the dashboard language between English and Simplified Chinese via a dropdown in the navigation bar.

src/DotNetCore.CAP.Dashboard/wwwroot/src/components · high confidence

The dashboard's frontend assets have been rebuilt, introducing a new Nodes view that allows users to select namespaces, view node details, and switch active nodes with latency monitoring. Additionally, the Published and Received message lists now support bulk selection, enabling users to delete or requeue (for published) and re-execute (for received) multiple messages at once.

src/DotNetCore.CAP.Dashboard/wwwroot/dist · high confidence

The CAP Dashboard's client-side interface has been rebuilt using Vue 2 and the Vite build tool, replacing the previous Razor-based implementation. This change introduces a modern JavaScript-based UI with client-side routing for views such as Home, Published, Received, Subscriber, and Nodes, and includes a new development configuration (vite.config.js) to proxy API requests to the backend service.

src/DotNetCore.CAP.Dashboard/wwwroot · high confidence

The project replaces its previous build process with a new FlubuCore build script that automates cleaning, restoring, building, testing, and packaging. A key behavioral change is the introduction of dynamic versioning: the build system reads version components from build/version.props and automatically appends a timestamped suffix (e.g., 'preview-...' or 'dv-...') to non-tagged builds, while tagged releases remain unmodified. This ensures that CI builds produce unique, traceable package versions without manual intervention.

build · high confidence

The Azure Service Bus sample has been replaced with an in-memory storage variant that demonstrates publishing to multiple topics and configuring custom message headers (including a Snowflake ID) and SQL filters for subscriptions.

samples/Sample.AzureServiceBus.InMemory · high confidence

The CAP Kafka transport has been refactored for version 3.0, introducing a dedicated \KafkaOptions\ configuration class and a new \ConnectionPool\ to manage producer instances. Users can now configure the producer connection pool size via \ConnectionPoolSize\ (default 10) and define topic creation settings (partitions, replication factor) through \TopicOptions\. The transport now supports custom headers via a \CustomHeadersBuilder\ delegate and allows overriding the default retryable error codes. Additionally, the implementation includes a \KafkaCapOptionsExtension\ for service registration and supports topic regex patterns for subscription.

src/DotNetCore.CAP.Kafka · high confidence

The MySQL storage provider has been restructured to introduce \EFOptions\ and \MySqlOptions\, allowing users to configure CAP using either a direct connection string or an existing Entity Framework Core \DbContext\. This change adds extension methods (\UseMySql\, \UseEntityFramework\<TContext\>\) to register the storage and includes a validation check that prevents using \ICapPublisher\ within the \DbContext\ to avoid circular references. Additionally, the implementation now supports distributed storage locks for multi-instance scenarios, with automatic detection of MySQL 8.0+ and MariaDB 10.6+ to enable \SKIP LOCKED\ optimizations, and introduces new database indexes on the \published\ and \received\ tables to improve query performance for delayed and expired messages.

src/DotNetCore.CAP.MySql · high confidence

The library now provides a structured filter mechanism for message subscribers, introducing the ISubscribeFilter interface and an abstract SubscribeFilter base class. This change replaces the previous synchronous filter approach with an async model, allowing developers to intercept subscriber execution via OnSubscribeExecutingAsync, OnSubscribeExecutedAsync, and OnSubscribeExceptionAsync. To support this, new context classes (ExecutingContext, ExecutedContext, ExceptionContext, and FilterContext) have been added to pass execution state and arguments through the filter pipeline.

src/DotNetCore.CAP/Internal/Filter · high confidence

The CAP messaging layer introduces a new core message model to standardize how messages are represented and processed. A new \Headers\ class defines standard metadata keys (such as \cap-msg-id\, \cap-corr-id\, and \cap-exec-instance-id\) used for tracking, correlation, and distributed tracing. The \Message\ class now serves as the primary unit of communication, containing a headers dictionary and a payload value, supported by extension methods for easy header access. Additionally, a \TransportMessage\ struct is added to handle raw byte data at the transport level for performance optimization, and a \FailedInfo\ class is introduced to provide detailed context (including the service provider) when invoking failure callbacks.

src/DotNetCore.CAP/Messages · high confidence

The PostgreSQL storage module has been rewritten to support configuring the database via an Entity Framework Core DbContext or directly via an NpgsqlDataSource, replacing the previous direct connection string approach. This change introduces new extension methods (UsePostgreSql, UseEntityFramework) and options classes (PostgreSqlOptions, EFOptions) that allow users to leverage existing EF Core connection configurations or custom Npgsql data sources. The refactoring also updates the transaction handling to properly wrap EF Core transactions and ensures that the storage initializer creates database tables and indexes within a configurable schema.

src/DotNetCore.CAP.PostgreSql · high confidence

The RabbitMQ transport implementation has been restructured to improve reliability and configurability. A new \ConnectionChannelPool\ manages RabbitMQ connections and channels, supporting cluster configurations via comma-separated hostnames and allowing custom \ConnectionFactory\ options. The consumer logic now uses a dedicated \RabbitMqBasicConsumer\ that safely copies message bodies for concurrent processing and supports custom headers via a builder function. Configuration is centralized in \RabbitMQOptions\, exposing settings for queue durability, TTL, queue type, and BasicQos prefetch counts. The transport also enforces durable exchanges and queues by default and handles channel state inconsistencies to prevent faulty channels from being returned to the pool.

src/DotNetCore.CAP.RabbitMQ · high confidence

The dashboard's gateway proxy implementation has been refactored to improve reliability and testability. The new \GatewayProxyAgent\ now explicitly respects the node port when constructing downstream request URIs, addressing previous issues where port configuration might be ignored. Additionally, the HTTP client layer has been restructured with a dedicated \RequestMapper\ for converting ASP.NET Core requests to \HttpRequestMessage\ objects and a \MemoryHttpClientCache\ that pools and reuses \HttpClient\ instances per target node, reducing connection overhead and improving stability during node switching.

src/DotNetCore.CAP.Dashboard/GatewayProxy · high confidence

The internal \src/DotNetCore.CAP/Internal\ folder has been restructured to improve how CAP discovers, selects, and executes consumer methods. A new \ConsumerExecutorDescriptor\ now encapsulates method metadata, including support for partial topic attributes (combining class and method names) and topic name prefixes. The \ConsumerServiceSelector\ has been updated to scan assemblies for \ICapSubscribe\ implementations and resolve subscriber types from DI implementation factories, ensuring correct type detection. Additionally, a \ConsumerExecutorDescriptorComparer\ was added to detect and log duplicate subscribers within the same group, and the \Bootstrapper\ now exposes manual start/stop capabilities via \BootstrapAsync\ and \StopAsync\ for better lifecycle control.

src/DotNetCore.CAP/Internal · high confidence

The internal message processing engine has been restructured from a monolithic dispatcher into a modular pipeline of distinct processor components. The new \CapProcessingServer\ orchestrates a set of specialized processors: \TransportCheckProcessor\ for connection health, \MessageNeedToRetryProcessor\ for handling failed messages with distributed locking, \MessageDelayedProcessor\ for scheduling delayed messages, and \CollectorProcessor\ for cleaning up expired data. This change is wrapped in an \InfiniteRetryProcessor\ to ensure resilience, and the \Dispatcher\ now utilizes .NET \Channel\ types for efficient, thread-safe message scheduling and parallel execution control.

src/DotNetCore.CAP/Processor · high confidence

The src/Cap.Consistency/Properties/AssemblyInfo.cs file has been deleted. This file previously contained manual assembly metadata attributes (such as company, product, and GUID information) and COM visibility settings. Its removal indicates a migration to modern .NET project SDK-style defaults, where such metadata is typically managed via the project file (.csproj) or generated automatically, simplifying the project structure.

src/Cap.Consistency/Properties · high confidence

The SQL Server storage backend has been rewritten to replace the previous Dapper-based implementation with direct ADO.NET and Entity Framework integration. This change introduces new configuration options via \EFOptions\ and \SqlServerOptions\, allowing users to specify a custom database schema and explicitly enable compatibility mode for SQL Server 2008. The refactoring also adds support for Entity Framework \DbContext\ transactions through new \BeginTransaction\ extension methods on \DatabaseFacade\, ensuring that CAP messages are persisted within the same transaction scope as application database changes. Additionally, the storage initializer now creates optimized non-clustered indexes on the published and received message tables to improve query performance.

src/DotNetCore.CAP.SqlServer · high confidence

The SQL Server transport now uses SqlClient diagnostic events to ensure that messages are only sent after the underlying database transaction has successfully committed. Previously, messages could be published or remain in the buffer even if the transaction rolled back or failed; this change prevents stale or uncommitted messages from being delivered to subscribers by tracking the transaction state via the \DiagnosticObserver\ and only committing/disposing the CAP transaction upon receiving the \WriteTransactionCommitAfter\ event.

src/DotNetCore.CAP.SqlServer/Diagnostics · high confidence

The Azure Service Bus transport now uses a dedicated helper to consistently determine the broker address. It accepts either a namespace or a connection string, extracting the namespace from the connection string's Endpoint property when necessary, and throws clear errors if neither is provided or if the endpoint cannot be parsed.

src/DotNetCore.CAP.AzureServiceBus/Helpers · high confidence

Added fake in-memory transport for unit testing; Added integration tests for cancellation token support in subscribers; Added test helper utilities for CAP integration testing; Added unit tests for Azure Service Bus transport configuration and helper logic; Added unit tests for CAP core components and consumer selection; Added unit tests for MySQL storage integration; Expose internal members to the test project.

The project has been upgraded to target .NET 10, with the core library and most transport/storage implementations now targeting .NET 8, while MySQL, PostgreSQL, and SQL Server providers support .NET 8, 9, and 10. Key dependencies have been updated, including Confluent.Kafka to 2.14.2, MongoDB.Driver to 3.9.0, RabbitMQ.Client to 7.2.1, and Microsoft.Data.SqlClient to 7.0.1. The build system now uses FlubuCore 10.1.0, and the dashboard's frontend dependencies (Vue, Vite, etc.) have been refreshed.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 58 → 55 (-2.5)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 58 → 56 (-2.0)
• Architecture 86 → 86 (+0.1)
• Maturity 77 → 77 (+0.3)
• Readiness 52 → 49 (-3.1)
• Security 61 → 56 (-4.7)
• Accessibility 66 → 70 (+3.5)
• Performance 66 → 66 (-0.2)

• Bounded contexts not declared
• CRAP 34: AzureServiceBusTransport.SendAsync (src/DotNetCore.CAP.AzureServiceBus/ITransport.AzureServiceBus.cs)
• Change coupling: IConnectionPool.LazyConnection.cs ↔ IConsumerClient.Redis.cs (src/DotNetCore.CAP.RedisStreams/IConnectionPool.LazyConnection.cs)
• Change coupling: IConnectionPool.LazyConnection.cs ↔ IRedisStream.Manager.Default.cs (src/DotNetCore.CAP.RedisStreams/IConnectionPool.LazyConnection.cs)
• Change coupling: IConnectionPool.LazyConnection.cs ↔ IRedisStream.Manager.Extensions.cs (src/DotNetCore.CAP.RedisStreams/IConnectionPool.LazyConnection.cs)
• Change coupling: IConnectionPool.LazyConnection.cs ↔ TransportMessage.Redis.cs (src/DotNetCore.CAP.RedisStreams/IConnectionPool.LazyConnection.cs)
• Change coupling: IConsumerClient.Redis.cs ↔ IRedisStream.Manager.Default.cs (src/DotNetCore.CAP.RedisStreams/IConsumerClient.Redis.cs)
• Change coupling: IConsumerClient.Redis.cs ↔ IRedisStream.Manager.Extensions.cs (src/DotNetCore.CAP.RedisStreams/IConsumerClient.Redis.cs)
• Change coupling: IConsumerClientFactory.Redis.cs ↔ IRedisStream.Manager.Default.cs (src/DotNetCore.CAP.RedisStreams/IConsumerClientFactory.Redis.cs)
• Change coupling: IConsumerClientFactory.Redis.cs ↔ TransportMessage.Redis.cs (src/DotNetCore.CAP.RedisStreams/IConsumerClientFactory.Redis.cs)
• Change coupling: IRedisStream.Manager.Default.cs ↔ TransportMessage.Redis.cs (src/DotNetCore.CAP.RedisStreams/IRedisStream.Manager.Default.cs)
• Critical CVE: [GHSA redacted] (src/DotNetCore.CAP.Dashboard/wwwroot/package-lock.json)
• Duplicated block (10 lines × 2) (src/DotNetCore.CAP.Dashboard/NodeDiscovery/CAP.ConsulDiscoveryOptionsExtensions.cs)
• Duplicated block (11 lines × 2) (src/DotNetCore.CAP.Dashboard/RouteActionProvider.cs)
• Duplicated block (12 lines × 2) (src/DotNetCore.CAP.Dashboard/RouteActionProvider.cs)
• Duplicated block (12 lines × 3) (src/DotNetCore.CAP.SqlServer/IDbConnection.Extensions.cs)
• Duplicated block (12 lines × 3) (src/DotNetCore.CAP.SqlServer/IDbConnection.Extensions.cs)
• Duplicated block (13 lines × 2) (src/DotNetCore.CAP.MongoDB/IDataStorage.MongoDB.cs)
• Duplicated block (13 lines × 3) (src/DotNetCore.CAP.SqlServer/IDbConnection.Extensions.cs)
• Duplicated block (17 lines × 2) (src/DotNetCore.CAP.Dashboard/RouteActionProvider.cs)
• …and 33 more

• Boundary-crossing change coupling: IStorageInitializer.PostgreSql.cs ↔ IDataStorage.SqlServer.cs (src/DotNetCore.CAP.PostgreSql/IStorageInitializer.PostgreSql.cs)
• Boundary-crossing change coupling: KafkaConsumerClient.cs ↔ RabbitMQConsumerClientFactory.cs (src/DotNetCore.CAP.Kafka/KafkaConsumerClient.cs)
• CRAP 90: MySqlMonitoringApi.GetMessagesAsync (src/DotNetCore.CAP.MySql/IMonitoringApi.MySql.cs)
• Change coupling: IConsumerServiceSelector.Default.cs ↔ MethodMatcherCache.cs (src/DotNetCore.CAP/Internal/IConsumerServiceSelector.Default.cs)
• Change coupling: IDataStorage.PostgreSql.cs ↔ IStorageInitializer.PostgreSql.cs (src/DotNetCore.CAP.PostgreSql/IDataStorage.PostgreSql.cs)
• Change coupling: IDataStorage.SqlServer.cs ↔ IStorageInitializer.SqlServer.cs (src/DotNetCore.CAP.SqlServer/IDataStorage.SqlServer.cs)
• CommentedOutCode (src/DotNetCore.CAP.Dashboard/CAP.MetricsEventListener.cs)
• CommentedOutCode (src/DotNetCore.CAP/Internal/ObjectMethodExecutor/ObjectMethodExecutor.cs)
• ContradictedWarningsAsErrors (samples/Sample.Kafka.PostgreSql/Sample.Kafka.PostgreSql.csproj)
• ContradictedWarningsAsErrors (src/DotNetCore.CAP.AzureServiceBus/DotNetCore.CAP.AzureServiceBus.csproj)
• ContradictedWarningsAsErrors (src/DotNetCore.CAP.Kafka/DotNetCore.CAP.Kafka.csproj)
• Critical CVE: [GHSA redacted] (src/DotNetCore.CAP.Dashboard/wwwroot/package-lock.json)
• Documentation: no architecture or design documentation (docs/content/user-guide/zh/storage/sqlserver.md)
• Documentation: no installation or build instructions (README.md)
• Documentation: no project overview (README.md)
• Documentation: written for insiders (docs/content/user-guide/zh/samples/faq.md)
• Duplicated block (10 lines × 2) (src/DotNetCore.CAP.Dashboard.K8s/K8sDiscoveryOptionsExtensions.cs)
• Duplicated block (10 lines × 3) (src/DotNetCore.CAP.MySql/IMonitoringApi.MySql.cs)
• Duplicated block (11 lines × 2) (src/DotNetCore.CAP.InMemoryStorage/IMonitoringApi.InMemory.cs)
• Duplicated block (11 lines × 3) (src/DotNetCore.CAP.MySql/IDataStorage.MySql.cs)
• …and 142 more

• 4 commits — 4 feature/other, 0 fixes

• docs/content — 4 commits

• change: docs: align transport guides with current APIs
• change: docs: correct storage schema guidance
• change: docs: fill source-backed configuration gaps
• change: docs: refresh release notes and site metadata

• Unchanged — 7 HTTP endpoints

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

dotnetcore/CAP was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.