Stratara.Mediator
4.4.4
Prefix Reserved
dotnet add package Stratara.Mediator --version 4.4.4
NuGet\Install-Package Stratara.Mediator -Version 4.4.4
<PackageReference Include="Stratara.Mediator" Version="4.4.4" />
<PackageVersion Include="Stratara.Mediator" Version="4.4.4" />
<PackageReference Include="Stratara.Mediator" />
paket add Stratara.Mediator --version 4.4.4
#r "nuget: Stratara.Mediator, 4.4.4"
#:package Stratara.Mediator@4.4.4
#addin nuget:?package=Stratara.Mediator&version=4.4.4
#tool nuget:?package=Stratara.Mediator&version=4.4.4
Stratara.Mediator
Derived. The behaviour described here is specified under
openspec/specs/. Those specifications are the source; this page explains and illustrates them.
License: MIT.
In-process mediator with DI-resolved handlers and pipeline behaviors. Drop-in replacement for MediatR-style routing without the runtime cost of MethodInfo.Invoke — uses a typed wrapper cache and direct DI dispatch.
Quick start
services.AddMediator()
.AddCommandHandlersFromAssemblyContaining<Program>()
.AddQueryHandlersFromAssemblyContaining<Program>()
.AddPipelineBehaviorWithResult(typeof(LoggingBehavior<,>))
.AddPipelineBehavior(typeof(LoggingBehavior<>));
// Optional: wrap in authorization decorator
services.AddAuthorizingMediator<MyAuthorizationProvider>();
Every dispatch is traced as a span named Handle <RequestType>. The spans come from the
Stratara.Application activity source — subscribe to it and they appear; register your own
OpenTelemetry Tracer and the mediator uses that instead. Nothing has to be registered for the
mediator to start.
IMediator is registered scoped. Resolve it from a scope (a request scope in ASP.NET Core, or
an explicit IServiceProvider.CreateScope() in a console host) — resolving it from the root
provider throws.
What's in the box
IMediator.HandleAsync<TResult>(IRequest<TResult>, CancellationToken)— routes queries and commands-with-result toIQueryHandler<TRequest, TResult>through any registeredIPipelineBehavior<TRequest, TResult>chain.IMediator.HandleAsync<TRequest>(TRequest, CancellationToken)— routes void commands toICommandHandler<TRequest>through any registeredIPipelineBehavior<TRequest>chain.AuthorizingMediatordecorator — checks[RequireRole]attributes viaIAuthorizationProviderand[RequirePermission]attributes viaIPermissionResolver(both AND) on the request's runtime type before delegating to the inner mediator. Its startup validator fails fast when a permission-guarded type is registered without an authorizing mediator or without a resolver, so a guard can never be silently skipped.BucketLockPool— concurrency primitive that serialisesIAggregateScopedCommanddispatch per bucket id. Used by message-bus consumers (e.g. theMediatorCommandWorkerinStratara.Outbox.RabbitMQ) to keep aggregate writes single-writer.
Pipeline behavior contract
Behaviors run outer-to-inner in DI registration order:
public sealed class LoggingBehavior<TRequest, TResult> : IPipelineBehavior<TRequest, TResult>
where TRequest : IRequest<TResult>
{
public async Task<TResult> HandleAsync(
TRequest request, Func<Task<TResult>> next, CancellationToken cancellationToken)
{
// before
var result = await next();
// after
return result;
}
}
Tenant isolation
AddStrataraTenantIsolation() registers a pipeline behavior that enforces tenant isolation at the
mediator entrance — before the handler runs — for any request that opts in by implementing the
ITenantScopedRequest marker. Requests that do not implement the marker pass through untouched.
public sealed record GetCustomerQuery(Guid CustomerId, Guid TenantId)
: IQuery<CustomerDto>, ITenantScopedRequest;
services
.AddStrataraValidation() // validation stays outermost
.AddStrataraTenantIsolation(); // then tenant isolation
The behavior compares the request's TenantId (the data owner) against the ambient session's
data-owner tenant (SessionContext.TenantId), not the actor tenant (SessionContext.ActorTenantId).
A request whose payload names a different tenant than the established session subject is rejected with
TenantAccessDeniedException (translated to HTTP 403 on ASP.NET hosts that register
AddStrataraProblemDetails() from Stratara.ServiceDefaults.AspNetCore, or 401 for a caller that is not authenticated; surfaced through the
message-failure path on workers).
Default vs. strict mode
TenantIsolationMode.Default— enforces only the subject match. A privileged cross-tenant operation (actor tenant ≠ data-owner tenant) passes, because the calling endpoint is expected to have promoted the session's data-owner tenant to the target before dispatch.TenantIsolationMode.Strict— additionally routes every cross-tenant operation through anICrossTenantAuthorizer. Stratara registers a deny-all default (viaTryAdd), so strict mode rejects all cross-tenant access until you register your own authorizer that grants it:
services.AddStrataraTenantIsolation(o => o.Mode = TenantIsolationMode.Strict);
services.AddScoped<ICrossTenantAuthorizer, PlatformAdminCrossTenantAuthorizer>();
internal sealed class PlatformAdminCrossTenantAuthorizer(IHttpContextAccessor http)
: ICrossTenantAuthorizer
{
public ValueTask<bool> IsCrossTenantAllowedAsync(SessionContext session, CancellationToken ct) =>
ValueTask.FromResult(http.HttpContext?.User.IsInRole("PlatformAdmin") ?? false);
}
The behavior runs both in-process (queries via
IMediatorat the endpoint, whereHttpContextis available) and worker-side (commands dispatched through the outbox, where there is noHttpContext). AnICrossTenantAuthorizerthat needs request-role state should be applied on the in-process path; the worker path must base its decision on theSessionContextalone.
Dependencies
Stratara.Abstractions— forIMediator/IRequest/ICommand/IQuery/IPipelineBehaviorcontracts, plusITenantScopedRequest/ICrossTenantAuthorizer/TenantAccessDeniedException.Stratara.Diagnostics— log-event IDs for the tenant-isolation behavior.Microsoft.Extensions.DependencyInjection.Abstractions.Microsoft.Extensions.Logging.Abstractions.OpenTelemetry.Api— emits anActivityper dispatch under theStratara.Applicationsource.
No EF Core, no message bus, no event sourcing. Library-safe.
| 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.Hosting.Abstractions (>= 10.0.11)
- Microsoft.Extensions.Logging.Abstractions (>= 10.0.11)
- Microsoft.Extensions.Options (>= 10.0.11)
- OpenTelemetry.Api (>= 1.18.0)
- Stratara.Abstractions (>= 4.4.4)
- Stratara.Diagnostics (>= 4.4.4)
NuGet packages (3)
Showing the top 3 NuGet packages that depend on Stratara.Mediator:
| Package | Downloads |
|---|---|
|
Stratara.Validation
Vendor-neutral request validation for the Stratara framework — a mediator pipeline behavior that runs IValidator<T> implementations before the handler and throws an aggregated StrataraValidationException on failure. No FluentValidation dependency; an optional adapter is shipped separately. |
|
|
Stratara.Outbox.RabbitMQ
Outbox-pattern command and event dispatch for the Stratara event-sourced stack — RabbitMQ IMessageBus implementation, retry worker, mediator command worker, and Redis-coordinated projection-replay state. Azure Service Bus support ships as the sibling Stratara.Outbox.AzureServiceBus package. |
|
|
Stratara.Infrastructure
Infrastructure glue for the Stratara framework — authorization decorators, configuration providers, and DI composition helpers that wire Mediator, Outbox, Identity, and EF Core into a hosted app. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 4.4.4 | 124 | 10/10/2026 |
| 4.4.3 | 74 | 10/10/2026 |
| 4.4.2 | 425 | 10/2/2026 |
| 4.4.1 | 461 | 9/29/2026 |
| 4.4.0 | 188 | 9/27/2026 |
| 4.3.1 | 171 | 9/25/2026 |
| 4.3.0 | 436 | 9/23/2026 |
| 4.2.0 | 201 | 9/18/2026 |
| 4.1.1 | 140 | 9/16/2026 |
| 4.1.0 | 140 | 9/16/2026 |
| 4.0.4 | 979 | 9/14/2026 |
| 4.0.3 | 230 | 9/3/2026 |
| 4.0.2 | 660 | 9/3/2026 |
| 4.0.1 | 379 | 9/2/2026 |
| 4.0.0 | 691 | 8/31/2026 |
| 4.0.0-preview.1 | 92 | 8/31/2026 |
| 3.4.0 | 180 | 8/28/2026 |
| 3.3.0 | 383 | 8/25/2026 |
| 3.2.3 | 171 | 8/22/2026 |
| 3.2.2 | 785 | 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.