Stratara.Mediator 3.1.4

.NET 10.0 This package targets .NET 10.0. The package is compatible with this framework or higher. 
dotnet add package Stratara.Mediator --version 3.1.4
                    


                    

                
NuGet\Install-Package Stratara.Mediator -Version 3.1.4
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package. 
<PackageReference Include="Stratara.Mediator" Version="3.1.4" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
<PackageVersion Include="Stratara.Mediator" Version="3.1.4" />
                    


                            Directory.Packages.props
                        

                    

                
<PackageReference Include="Stratara.Mediator" />
                    


                            Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package. 
paket add Stratara.Mediator --version 3.1.4
                    


                    

                
#r "nuget: Stratara.Mediator, 3.1.4"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package. 
#:package Stratara.Mediator@3.1.4
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package. 
#addin nuget:?package=Stratara.Mediator&version=3.1.4
                    


                            Install as a Cake Addin
                        

                    

                
#tool nuget:?package=Stratara.Mediator&version=3.1.4
                    


                            Install as a Cake Tool

Stratara.Mediator

License: FSL-1.1-MIT (Functional Source License — source-available; converts to MIT after 2 years). Not OSI-approved OSS.

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>();

What's in the box

  • IMediator.HandleAsync<TResult>(IRequest<TResult>, CancellationToken) — routes queries and commands-with-result to IQueryHandler<TRequest, TResult> through any registered IPipelineBehavior<TRequest, TResult> chain.
  • IMediator.HandleAsync<TRequest>(TRequest, CancellationToken) — routes void commands to ICommandHandler<TRequest> through any registered IPipelineBehavior<TRequest> chain.
  • AuthorizingMediator decorator — checks [RequireRole] attributes on the request type via IAuthorizationProvider before delegating to the inner mediator.
  • BucketLockPool — concurrency primitive that serialises IAggregateScopedCommand dispatch per bucket id. Used by message-bus consumers (e.g. Stratara.Infrastructure's MediatorCommandWorker) 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 by AuthorizationExceptionMiddleware on ASP.NET hosts; 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 an ICrossTenantAuthorizer. Stratara registers a deny-all default (via TryAdd), 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 IMediator at the endpoint, where HttpContext is available) and worker-side (commands dispatched through the outbox, where there is no HttpContext). An ICrossTenantAuthorizer that needs request-role state should be applied on the in-process path; the worker path must base its decision on the SessionContext alone.

Dependencies

  • Stratara.Abstractions — for IMediator/IRequest/ICommand/IQuery/IPipelineBehavior contracts, plus ITenantScopedRequest/ICrossTenantAuthorizer/TenantAccessDeniedException.
  • Stratara.Diagnostics — log-event IDs for the tenant-isolation behavior.
  • Microsoft.Extensions.DependencyInjection.Abstractions.
  • Microsoft.Extensions.Logging.Abstractions.
  • OpenTelemetry.Api — emits an Activity per dispatch under the Stratara.Application source.

No EF Core, no message bus, no event sourcing. Library-safe.

Product 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. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

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
3.1.4 37 6/15/2026
3.1.3 94 6/10/2026
3.1.2 162 6/5/2026
3.1.1 740 6/1/2026
3.1.0 145 5/30/2026
3.0.23 144 5/28/2026

### Added

- **Command-workload isolation (heavy-command lane)** — long-running commands can now be routed to a
 dedicated worker lane so they cannot starve interactive commands. Mark a command with the new
 `Stratara.Abstractions.Mediator.IHeavyCommand` marker and the `ICommandOutboxDispatcher`
 automatically publishes it to a separate heavy-command topic (`IMessagingIdentifier.HeavyCommandTopic` /
 `HeavyCommandSubscription`, configurable under `Messaging:HeavyCommand`, defaulting to `heavy-command` /
 `heavy-command-subscription`). Run a dedicated heavy-command worker with the new
 `services.AddHeavyCommandWorker(degreeOfParallelism?)` extension, or the
 `builder.AddHeavyCommandWorkerServices(degreeOfParallelism?)` host composite — in the same process as
 the interactive worker (two lanes) or in a separately scaled host. Each worker's degree of parallelism
 is configurable per lane. `IMessagingIdentifier` gains `HeavyCommandTopic`, `HeavyCommandSubscription`,
 and the `GetCommandTopic(Type)` / `GetCommandSubscription(Type)` routing helpers. The interactive lane
 (`AddMediatorWorker()`) is unchanged and remains the default; commands not marked heavy keep their
 existing routing. If a heavy command is dispatched while no heavy worker is bound, the publish is
 rejected and the command is preserved in the outbox until a heavy-command worker comes online — it is
 never dropped. Works over both the RabbitMQ and Azure Service Bus message buses (Azure Service Bus
 requires the heavy-command topic/subscription to be provisioned, like the existing command topic). New
 log-event ID `105_005` (`CommandWorkerLaneStarted`) in `Stratara.Diagnostics`.
- **Observability metrics across the worker pipeline** (`Stratara.Diagnostics`) — the shared
 `Stratara.Service` meter now publishes throughput and latency instruments so operators can see how the
 event-sourcing pipeline is behaving instead of flying blind on a single counter. New instruments:
 `event_source.events.appended` (counter, tagged by `event.type` / `aggregate.type`),
 `outbox.published` (counter, tagged by `outbox.kind` = `command` / `event`), `command.duration`
 (histogram, ms, tagged by `request.type` / `outcome`), `projection.events.processed` (counter) +
 `projection.bundle.duration` (histogram, ms), `saga.events.processed` (counter) +
 `saga.bundle.duration` (histogram, ms), and `saga.inflight` (up/down counter). They are recorded by the
 event source, command worker, projection worker, saga worker, and outbox worker respectively. Because
 projections and sagas are real-time bus subscribers without a persisted checkpoint, these report
 **throughput and latency**, not consumer lag. No configuration is required — point any OpenTelemetry
 metrics exporter at the `Stratara.Service` meter.
- **Operational health checks for the event store and outbox** (`Stratara.EventSourcing.EntityFrameworkCore`) —
 two opt-in readiness checks added to any `IHealthChecksBuilder`: `AddEventStoreHealthCheck()` verifies
 the write-side database is reachable, and `AddOutboxHealthCheck(degradedThreshold?, unhealthyThreshold?)`
 reports the pending outbox backlog (exposed under the `pending` data key) and escalates to
 `Degraded` / `Unhealthy` when the backlog crosses the supplied thresholds. Both are tagged `ready` by
 default (so they map to a readiness endpoint, not liveness) and require the Stratara write store to be
 registered. The write-store DbContext is now also resolvable as a scoped `IWriteDbContext` service to
 support these checks.
- **Polly-backed mediator resilience behavior** (`Stratara.Resilience`) — an opt-in pipeline behavior
 wraps the in-process dispatch of a request marked with the new
 `Stratara.Abstractions.Resilience.IResilientRequest` in the named Polly pipeline the request selects
 (`ResiliencePipelineName`). Register it with the new `AddStrataraResilienceBehavior()` (after
 `AddStrataraValidation()` / `AddStrataraTenantIsolation()` so the retry wraps the handler, not the
 guards); requests without the marker are unaffected. A new built-in pipeline
 `ResilienceNames.ConcurrencyConflict` retries **only** on
 `Stratara.Abstractions.Persistence.ConcurrencyConflictException` (5 attempts, short exponential
 backoff) so a handler that re-reads and re-applies on an optimistic-concurrency clash succeeds without
 bespoke retry loops; it is registered by `AddResiliencePipelines()` alongside the existing message-bus
 and dispatcher pipelines. Only mark handlers that are safe to re-run (idempotent or concurrency-guarded).