Stratara.EventSourcing.Pipeline.CommandAudit
4.4.4
Prefix Reserved
dotnet add package Stratara.EventSourcing.Pipeline.CommandAudit --version 4.4.4
NuGet\Install-Package Stratara.EventSourcing.Pipeline.CommandAudit -Version 4.4.4
<PackageReference Include="Stratara.EventSourcing.Pipeline.CommandAudit" Version="4.4.4" />
<PackageVersion Include="Stratara.EventSourcing.Pipeline.CommandAudit" Version="4.4.4" />
<PackageReference Include="Stratara.EventSourcing.Pipeline.CommandAudit" />
paket add Stratara.EventSourcing.Pipeline.CommandAudit --version 4.4.4
#r "nuget: Stratara.EventSourcing.Pipeline.CommandAudit, 4.4.4"
#:package Stratara.EventSourcing.Pipeline.CommandAudit@4.4.4
#addin nuget:?package=Stratara.EventSourcing.Pipeline.CommandAudit&version=4.4.4
#tool nuget:?package=Stratara.EventSourcing.Pipeline.CommandAudit&version=4.4.4
Stratara.EventSourcing.Pipeline.CommandAudit
Derived. The behaviour described here is specified under
openspec/specs/. Those specifications are the source; this page explains and illustrates them.
License: MIT.
Mediator pipeline behavior that records an audit row for every dispatched command in the Stratara event-sourced stack. Both arities are provided so consumers can register a single behavior pair and have it apply to all command shapes.
What's in the box
| Type | Purpose |
|---|---|
AddCommandAuditing() |
The package's public surface — registers both behavior arities in one call. |
CommandAuditBehavior<TRequest> (internal) |
Runs the audit-write step before delegating to next() for IRequest (commands without result). |
CommandAuditBehavior<TRequest, TResult> (internal) |
Same, for IRequest<TResult> (commands with result + queries). Only records when the request also implements ICommandBase — queries flow through untouched. |
CommandAuditWriter (internal) |
Opens a transaction on IWriteUnitOfWork, writes via ICommandAuditRepository.AddAsync, commits. |
The behavior only audits commands — query requests reach the same generic interface but are filtered by the is ICommandBase check, so registering both behaviors application-wide is safe.
Quick start
// At composition time, alongside the other framework pipeline behaviors:
builder.Services.AddCommandAuditing();
That one call registers both behavior arities. The behavior types themselves are internal — they
are an implementation detail, not something to name from your composition root.
The behaviors resolve IWriteUnitOfWork from DI (ships with Stratara.EventSourcing.EntityFrameworkCore in the default deployment). No additional registration is needed.
Dependencies
Stratara.Abstractions— forIPipelineBehavior<,>,IRequest/IRequest<T>,ICommandBase,IWriteUnitOfWork,ICommandAuditRepository.JetBrains.Annotations—[UsedImplicitly]on the public behavior classes (DI-instantiated, no static call site).
At runtime an IWriteUnitOfWork implementation must be registered — typically by referencing Stratara.EventSourcing.EntityFrameworkCore and calling AddWriteStore(IConfiguration).
Security note — command payload contents
The audit row stores CommandTypeName and the serialized CommandJson of the dispatched command. Whatever fields your commands carry land in the audit table. Sensitive data (passwords, tokens, API keys, encryption material) MUST NOT live on a command record — or must be marked with [EncryptData] so the registered ISecureJsonSerializer encrypts them before persistence.
The default Stratara registration uses ISecureJsonSerializer (AES-GCM + tenant-scoped AAD) for the audit serialization, so [EncryptData]-annotated properties are protected. Plain-text properties go to disk unencrypted — treat the audit table accordingly when designing command shapes.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- JetBrains.Annotations (>= 2026.2.0)
- Stratara.Abstractions (>= 4.4.4)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 4.4.4 | 49 | 10/10/2026 |
| 4.4.3 | 72 | 10/10/2026 |
| 4.4.2 | 290 | 10/2/2026 |
| 4.4.1 | 347 | 9/29/2026 |
| 4.4.0 | 122 | 9/27/2026 |
| 4.3.1 | 118 | 9/25/2026 |
| 4.3.0 | 286 | 9/23/2026 |
| 4.2.0 | 129 | 9/18/2026 |
| 4.1.1 | 98 | 9/16/2026 |
| 4.1.0 | 97 | 9/16/2026 |
| 4.0.4 | 824 | 9/14/2026 |
| 4.0.3 | 110 | 9/3/2026 |
| 4.0.2 | 603 | 9/3/2026 |
| 4.0.1 | 321 | 9/2/2026 |
| 4.0.0 | 164 | 8/31/2026 |
| 4.0.0-preview.1 | 77 | 8/31/2026 |
| 3.4.0 | 146 | 8/28/2026 |
| 3.3.0 | 114 | 8/25/2026 |
| 3.2.3 | 110 | 8/22/2026 |
| 3.2.2 | 128 | 8/14/2026 |
A one-fix release. On the Redis-backed replay state, a host could report a replay still active after it had ended
it, holding publication back for up to one refresh interval. Nothing else changes; no configuration or migration is
needed.
### Fixed
- **A host no longer reports a replay active after it ended the replay itself.** On the Redis-backed replay state, a
refresh that had read the marking just before the host's own deactivation could compare its generation before the
deactivation and write the field after it, leaving `IsReplayActive` true — and publication held back — until the
next refresh (`ProjectionReplay:RefreshSeconds`, default 5). The comparison and the write are now one step with the
transition. Present since 4.4.2.