Stratara.Validation
4.0.2
Prefix Reserved
See the version list below for details.
dotnet add package Stratara.Validation --version 4.0.2
NuGet\Install-Package Stratara.Validation -Version 4.0.2
<PackageReference Include="Stratara.Validation" Version="4.0.2" />
<PackageVersion Include="Stratara.Validation" Version="4.0.2" />
<PackageReference Include="Stratara.Validation" />
paket add Stratara.Validation --version 4.0.2
#r "nuget: Stratara.Validation, 4.0.2"
#:package Stratara.Validation@4.0.2
#addin nuget:?package=Stratara.Validation&version=4.0.2
#tool nuget:?package=Stratara.Validation&version=4.0.2
Stratara.Validation
Derived. The behaviour described here is specified under
openspec/specs/. Those specifications are the source; this page explains and illustrates them.
License: MIT.
Vendor-neutral request validation for Stratara's CQRS pipeline. A mediator pipeline behavior
runs your IValidator<T> implementations before the handler and throws an aggregated
StrataraValidationException when validation fails — no third-party validation dependency in
the default path.
Quick start
// 1. Register the behavior (outermost) + discover validators.
builder.Services
.AddStrataraValidation()
.AddValidatorsFromAssemblyContaining<IAppMarker>();
// 2. Write a validator (the contracts live in Stratara.Abstractions.Validation).
public sealed class CreateOrderValidator : IValidator<CreateOrder>
{
public ValueTask<ValidationResult> ValidateAsync(CreateOrder cmd, CancellationToken ct = default)
=> ValueTask.FromResult(string.IsNullOrWhiteSpace(cmd.CustomerId)
? new ValidationResult([new ValidationFailure(nameof(cmd.CustomerId), "Customer is required.")])
: ValidationResult.Success);
}
// 3. Catch the failure in your global handler and map it to your error model.
catch (StrataraValidationException ex)
{
// ex.Failures -> RFC-7807 ProblemDetails 400, your error codes, etc.
}
How it works
AddStrataraValidation()registersIPipelineBehaviorfor both request shapes (IRequestandIRequest<TResult>). Register it before other behaviors so validation runs outermost — before authorization, auditing, and the handler.- All validators for a request run; their failures are aggregated.
- Severity policy: only
ValidationSeverity.Errorblocks (throwsStrataraValidationException).WarningandInfofailures pass through and are logged.
Contracts
The validation contracts (IValidator<T>, ValidationResult, ValidationFailure,
ValidationSeverity, StrataraValidationException) live in Stratara.Abstractions
(namespace Stratara.Abstractions.Validation) so consumers can implement validators and catch
the exception without referencing this behavior package.
The contract shape is FluentValidation-compatible; an optional
Stratara.Validation.FluentValidation adapter can be shipped to plug FluentValidation
validators into the same pipeline.
Dependencies
Stratara.AbstractionsStratara.MediatorStratara.DiagnosticsMicrosoft.Extensions.DependencyInjection.AbstractionsMicrosoft.Extensions.Logging.Abstractions
| 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)
- Microsoft.Extensions.DependencyInjection.Abstractions (>= 10.0.11)
- Microsoft.Extensions.Logging.Abstractions (>= 10.0.11)
- Stratara.Abstractions (>= 4.0.2)
- Stratara.Diagnostics (>= 4.0.2)
- Stratara.Mediator (>= 4.0.2)
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.0.3 | 35 | 9/3/2026 |
| 4.0.2 | 200 | 9/3/2026 |
| 4.0.1 | 95 | 9/2/2026 |
| 4.0.0 | 291 | 8/31/2026 |
| 4.0.0-preview.1 | 51 | 8/31/2026 |
| 3.4.0 | 123 | 8/28/2026 |
| 3.3.0 | 318 | 8/25/2026 |
| 3.2.3 | 93 | 8/22/2026 |
| 3.2.2 | 722 | 8/14/2026 |
| 3.2.1 | 354 | 8/2/2026 |
| 3.2.0 | 111 | 7/18/2026 |
| 3.1.7 | 120 | 7/1/2026 |
| 3.1.6 | 533 | 6/22/2026 |
| 3.1.5 | 131 | 6/22/2026 |
| 3.1.4 | 1,635 | 6/15/2026 |
| 3.1.3 | 125 | 6/10/2026 |
| 3.1.2 | 127 | 6/5/2026 |
| 3.1.1 | 863 | 6/1/2026 |
| 3.1.0 | 116 | 5/30/2026 |
Two operational fixes, both found while a consumer rolled out bus-envelope signing and reasoned
about rebuilding its read models: a projection replay now survives a passing failure, and an
integrity failure says whether the signature was absent or wrong. Additive on every published
surface.
### Added
- **A projection replay retries a failing batch before it gives up.** Each batch — the read from
the event store and the application of its entries — now runs under a new named policy,
`ResilienceNames.ProjectionReplayBatch`: five attempts in all, exponential backoff from one second
with jitter between them, any exception except cancellation. A read-store timeout or a
dropped connection mid-rebuild no longer ends the replay; a failure that persists through every
attempt ends it exactly as before, with the same failure record. A retried batch is applied
again from its first entry in a fresh scope, which relies on the guarantee projections already
give under at-least-once delivery: a second application converges (see *Write handlers that
converge rather than accumulate* in the projection guide). Each failed attempt logs a new
warning, `104_011`. `AddResiliencePipelines` registers six policies rather than five. Nothing
about truncation, ordering, progress, the failure record or the lease changes.
### Changed
- **An integrity failure now says whether the signature was absent or wrong, and the existing
warning and error ids fire only for a signature that is present and does not verify.** An
unsigned envelope — what every not-yet-restarted publisher emits during a `Permissive` roll —
was logged as *"signature mismatch"* under the same id as a key mismatch or tampering, so an
operator could not tell a rolling restart from an attack without correlating host start times.
Four new event ids carry the unsigned case: `105_004` (command, permissive), `111_004` (event
bundle, permissive), `105_105` (command, strict) and `111_105` (event bundle, strict). The
existing `105_003`, `111_003`, `105_104` and `111_104` keep their numbers and their level but
now mean a present signature that did not verify; an alert keyed on one of them goes quiet
during a roll instead of firing for every unsigned message. Strict-mode rejections name the
case in their exception message. `BusEnvelopeIntegrityVerifier.Verify` gains an overload with
`out BusEnvelopeIntegrityFailure` (`None`, `Absent`, `Invalid`); the existing overload and the
`BusEnvelopeIntegrityResult` values are unchanged. An absent signature no longer reaches the
signer, which already answered `false` for it.