Stratara.Sagas 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.Sagas --version 3.1.4
                    


                    

                
NuGet\Install-Package Stratara.Sagas -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.Sagas" Version="3.1.4" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
<PackageVersion Include="Stratara.Sagas" Version="3.1.4" />
                    


                            Directory.Packages.props
                        

                    

                
<PackageReference Include="Stratara.Sagas" />
                    


                            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.Sagas --version 3.1.4
                    


                    

                
#r "nuget: Stratara.Sagas, 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.Sagas@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.Sagas&version=3.1.4
                    


                            Install as a Cake Addin
                        

                    

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


                            Install as a Cake Tool

Stratara.Sagas

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

Saga runtime for the Stratara event-sourced stack. Discovers ISaga implementations in the consumer's application assemblies, dispatches event bundles to them, and runs them under the SagaWorker hosted service.

What's in the box

Folder Contents
Abstractions/ ISaga (marker for handler discovery), ISagaManager, ISagaHandler, ISagaMethodInvoker
Services/ SagaManager (event-bundle → matching saga fan-out), SagaHandler (per-saga scoped execution + retries), SagaMethodInvoker (reflection-cached method-pointer dispatch into consumer sagas), SagaWorker (hosted service consuming the event-bundle subscription), SagaOptions (subscription + concurrency knobs)
DependencyInjection/ AddSagaWorker(IConfiguration) + AddSagasFromAssemblyContaining<T>()

Quick start

// In your Saga worker:
builder.Services.AddSagaWorker(builder.Configuration);
builder.Services.AddSagasFromAssemblyContaining<MyAppSagaMarker>();

Then implement ISaga in your application assembly. The saga manager picks them up automatically and dispatches matching events to their handler methods.

public sealed class OrderShippingSaga(ICommandOutboxDispatcher dispatcher) : ISaga
{
    // Discovered via reflection — handler methods can be public or private.
    [JetBrains.Annotations.UsedImplicitly]
    private async Task HandleAsync(OrderPaidEvent @event, CancellationToken ct) =>
        await dispatcher.EnqueueCommandAsync(new ScheduleShipmentCommand(@event.OrderId), ct);
}

How sagas work

Lifecycle

  • Scoped per event bundle. Saga instances are resolved via IServiceScopeFactory.CreateScope() for every event bundle the SagaWorker consumes from the message bus. A fresh DI scope means transient dependencies (DbContext, repositories, the unit of work) are isolated per dispatch.
  • No durable instance state. Sagas are not persisted between bundles — Stratara does not keep a per-saga state row. Anything you need to remember across bundles must be persisted externally (event store, read store, the aggregate the saga decides about, or a dedicated saga-state aggregate).
  • At-least-once dispatch. The underlying event bundle subscription is at-least-once (see the Outbox package). Handler methods MUST be idempotent — typically by checkpointing the latest processed event version per stream, or by deduplicating against the event id.

Correlation

  • Routing key = event type. The SagaManager filters incoming bundles by the relevant event types each saga declares (via its HandleAsync method signatures). A saga only ever sees events it asked for.
  • Correlation across events is your responsibility: typically you use the aggregate id carried on the event (or a domain key like OrderId) to look up state, decide what to do, and emit a follow-up command via ICommandOutboxDispatcher.
  • The session context (correlation id, causation id, actor, subject) is restored from the wire envelope before handlers run, so source-generated LoggerSagaExtensions calls inside a handler are automatically scoped to the originating session.

State management

Sagas should drive state changes by emitting commands, not by mutating shared state directly. The recommended pattern:

[UsedImplicitly]
private async Task HandleAsync(ShipmentScheduledEvent @event, CancellationToken ct)
{
    var view = await readStore.GetOrderShippingViewAsync(@event.OrderId, ct);
    if (view is { State: ShippingState.AwaitingDispatch })
    {
        await dispatcher.EnqueueCommandAsync(new MarkOrderInTransitCommand(@event.OrderId), ct);
    }
}

The read view holds the current state, the command (via the outbox) advances it, and the next event triggers the next saga step. This keeps sagas stateless, testable, and replay-safe.

Annotations on consumer handlers

Handler methods are discovered via reflection, so static analyzers (R#, IDE, Roslyn) flag them as unused. Mark every handler with [JetBrains.Annotations.UsedImplicitly]:

[UsedImplicitly]
private async Task HandleAsync(InvoiceIssuedEvent @event, CancellationToken ct) { … }

The class itself (ISaga implementation) is registered through AddSagasFromAssemblyContaining<T>() and is also "used implicitly" — typically mark it [UsedImplicitly] as well, especially if you do not reference it directly elsewhere.

Dependencies

  • Stratara.Contracts — for EventBundle + IEvent<T>.
  • Stratara.Domain — for the framework's aggregate interfaces (sagas typically dispatch commands referencing tenant-scoped aggregates).
  • Stratara.Shared — for messaging primitives, the source-generated LoggerSagaExtensions diagnostics surface, and DI conventions.
  • Microsoft.Extensions.Hosting.Abstractions + Microsoft.Extensions.Options.ConfigurationExtensions — for SagaWorker hosting + SagaOptions binding.
  • JetBrains.Annotations — for static-analysis attributes on saga-handler conventions.
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 (1)

Showing the top 1 NuGet packages that depend on Stratara.Sagas:

Package Downloads
Stratara.EventSourcing.WorkerDefaults

Worker-host wiring composites for the Stratara event-sourced stack. IHostApplicationBuilder extensions (AddBackendServices, AddCommandWorkerServices, AddEventProjectionWorkerServices, AddSagaWorkerServices, AddOutboxWorkerServices) bundle the per-concern DI calls so each worker host opts in with one line.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
3.1.4 95 6/15/2026
3.1.3 109 6/10/2026
3.1.2 119 6/5/2026
3.1.1 195 6/1/2026
3.1.0 121 5/30/2026
3.0.23 110 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).