Stratara.Outbox.AzureServiceBus
4.4.8
Prefix Reserved
dotnet add package Stratara.Outbox.AzureServiceBus --version 4.4.8
NuGet\Install-Package Stratara.Outbox.AzureServiceBus -Version 4.4.8
<PackageReference Include="Stratara.Outbox.AzureServiceBus" Version="4.4.8" />
<PackageVersion Include="Stratara.Outbox.AzureServiceBus" Version="4.4.8" />
<PackageReference Include="Stratara.Outbox.AzureServiceBus" />
paket add Stratara.Outbox.AzureServiceBus --version 4.4.8
#r "nuget: Stratara.Outbox.AzureServiceBus, 4.4.8"
#:package Stratara.Outbox.AzureServiceBus@4.4.8
#addin nuget:?package=Stratara.Outbox.AzureServiceBus&version=4.4.8
#tool nuget:?package=Stratara.Outbox.AzureServiceBus&version=4.4.8
Stratara.Outbox.AzureServiceBus
Derived. The behaviour described here is specified under
openspec/specs/. Those specifications are the source; this page explains and illustrates them.
License: MIT.
Azure Service Bus implementation of Stratara.Abstractions.Messaging.IMessageBus. Publishes JSON-serialized messages to topics and exposes a subscription helper that wires up a Service Bus processor with per-message exception classification:
- success →
CompleteMessageAsync ConcurrencyException→AbandonMessageAsyncuntilMessageRetry:MaxConflictRequeuesredeliveries (default 100) have not resolved it, thenDeadLetterMessageAsyncwith reasonconflict- any other exception →
AbandonMessageAsyncuntilMessageRetry:MaxDeliveryAttemptsdeliveries (default 3) have failed, thenDeadLetterMessageAsyncwith reasonfailureand the exception in the description
The subscription's own MaxDeliveryCount must leave room for the bounds; a subscription created with Service Bus defaults allows 10 deliveries. Where the host can read the subscription, the bus lowers the bounds for it to fit and logs 108_111.
System-level errors (connection drops, auth failures) arrive via ProcessErrorAsync and are logged; the Service Bus client owns the reconnect / retry policy for those.
A subscription that stops closes its processor, which takes no further message and waits for its running handler — as long as the host's shutdown timeout allows while the application stops, twenty seconds otherwise; the host waits for that before it counts as stopped. A handler that gives up because the subscription stops has its message abandoned rather than dead-lettered by the framework; the broker counts that delivery like any other. A handler's outcome is settled whatever the subscription's own cancellation says, and a handler that failed because its save committed but could not publish has its message completed, not delivered again.
Install
dotnet add package Stratara.Outbox.AzureServiceBus
Register the bus in your DI composition — one call wires the ServiceBusClient, the envelope
options and the IMessageBus implementation:
// Connection string:
builder.Services.AddAzureServiceBus(builder.Configuration.GetConnectionString("ServiceBus")!);
// Or, preferred in Azure — managed identity, no secret in configuration:
builder.Services.AddAzureServiceBusWithManagedIdentity("my-namespace.servicebus.windows.net");
The AzureServiceBusBus implementation is internal; register it through these extensions rather
than by naming the type.
The explicitly-chosen transport wins.
AddAzureServiceBusreplaces theIMessageBusregistration, so it takes effect even when the RabbitMQ umbrella (builder.AddMessaging(), which the worker composites call) already claimed the slot. Still use one transport per host — calling both is a configuration smell — but an explicitAddAzureServiceBuswill no longer be a silent no-op behind a composite.
Notes
Pre-3.0 this implementation lived inside Stratara.Outbox.RabbitMQ. As of 3.0 the two transports are separate packages so a consumer who only wants RabbitMQ does not drag the Azure Service Bus SDK into the dependency tree (and vice versa).
| 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
- Azure.Identity (>= 1.21.0)
- Azure.Messaging.ServiceBus (>= 7.21.0)
- Microsoft.Extensions.DependencyInjection.Abstractions (>= 10.0.13)
- Microsoft.Extensions.Hosting.Abstractions (>= 10.0.13)
- Microsoft.Extensions.Logging.Abstractions (>= 10.0.13)
- Microsoft.Extensions.Options (>= 10.0.13)
- Microsoft.Extensions.Options.ConfigurationExtensions (>= 10.0.13)
- Stratara.Abstractions (>= 4.4.8)
- Stratara.Shared (>= 4.4.8)
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.8 | 44 | 10/24/2026 |
| 4.4.7 | 46 | 10/23/2026 |
| 4.4.6 | 66 | 10/22/2026 |
| 4.4.5 | 93 | 10/14/2026 |
| 4.4.4 | 96 | 10/10/2026 |
| 4.4.3 | 100 | 10/10/2026 |
| 4.4.2 | 103 | 10/2/2026 |
| 4.4.1 | 97 | 9/29/2026 |
| 4.4.0 | 98 | 9/27/2026 |
| 4.3.1 | 106 | 9/25/2026 |
| 4.3.0 | 102 | 9/23/2026 |
| 4.2.0 | 114 | 9/18/2026 |
| 4.1.1 | 109 | 9/16/2026 |
| 4.1.0 | 101 | 9/16/2026 |
| 4.0.4 | 115 | 9/14/2026 |
| 4.0.3 | 111 | 9/3/2026 |
| 4.0.2 | 116 | 9/3/2026 |
| 4.0.1 | 105 | 9/2/2026 |
| 4.0.0 | 109 | 8/31/2026 |
| 4.0.0-preview.1 | 77 | 8/31/2026 |
A fix for hosts on the Orleans execution model. A store reader that catches up a large backlog and a singleton
work that runs long now answer their keep-alive, so neither leaves reminder errors in the silo's log. A silo that
joins while a singleton work runs long on another silo no longer fails its start. No API change, no schema change
and no migration.
### Fixed
- **A busy store reader or singleton work answers its keep-alive.** On the Orleans execution model, a projection or
saga reader that caught up a backlog for longer than the runtime's response timeout made its keep-alive tick wait
behind the catch-up, and Orleans logged `Could not deliver reminder tick` at Error, once per partition and
keep-alive period. A singleton work whose run outlasted the timeout did the same. Nothing was lost, but a large
catch-up left dozens of errors on the silo. The keep-alive and the poll now start a catch-up where none is
running and do not wait for it. A partition is still read by one catch-up at a time, and a commit during a
catch-up is still applied by it. A singleton work's keep-alive interleaves with its run, and runs still never
overlap.
- **A silo starts while a singleton work runs long.** A silo that started while a singleton work it registers ran
longer than the response timeout on another silo waited for that run in its own start. The start then failed
with a `TimeoutException`. The call a starting silo makes to each singleton work and store reader now
interleaves, so the start goes on.
- *Operate the Orleans execution model* says that a durable timer whose handler outlasts the response timeout
still makes Orleans log `Could not deliver reminder tick` for that tick, and that the line says nothing about
the timer. It also says that, outside a deploy, the line now points to an unreachable store reader or singleton
work rather than a busy one.