Aaron.Akka.Durable.TestKit
0.1.0-alpha.5
dotnet add package Aaron.Akka.Durable.TestKit --version 0.1.0-alpha.5
NuGet\Install-Package Aaron.Akka.Durable.TestKit -Version 0.1.0-alpha.5
<PackageReference Include="Aaron.Akka.Durable.TestKit" Version="0.1.0-alpha.5" />
<PackageVersion Include="Aaron.Akka.Durable.TestKit" Version="0.1.0-alpha.5" />
<PackageReference Include="Aaron.Akka.Durable.TestKit" />
paket add Aaron.Akka.Durable.TestKit --version 0.1.0-alpha.5
#r "nuget: Aaron.Akka.Durable.TestKit, 0.1.0-alpha.5"
#:package Aaron.Akka.Durable.TestKit@0.1.0-alpha.5
#addin nuget:?package=Aaron.Akka.Durable.TestKit&version=0.1.0-alpha.5&prerelease
#tool nuget:?package=Aaron.Akka.Durable.TestKit&version=0.1.0-alpha.5&prerelease
Akka.Durable
Akka.Durable is a proof of concept, not an official Akka.NET project. It is published as Aaron.Akka.Durable because the Akka.* NuGet prefix is reserved for official Akka.NET packages. Expect breaking changes between releases.
Akka.Durable gives you event-sourced entities on Akka.NET. Define their behavior with pure Decide and Evolve functions, keep the impure work in effect handlers, then send commands through typed references. The runtime handles persistence, recovery, and routing in local or clustered deployments.
Inject it. Send a message.
Entity reference factories are .NET DI services. Call AddDurableEntities() at startup, then inject IEntityRefs<InvoiceCommand> into any controller, hosted service, or application service:
public sealed class BillingService(IEntityRefs<InvoiceCommand> invoices)
{
public Task<IssueReply> IssueAsync(EntityId id, CancellationToken ct) =>
invoices.Get(id).Ask(new IssueInvoice(250m, "billing@example.com"), ct);
public void Remind(EntityId id) =>
invoices.Get(id).Tell(new SendReminder());
}
That's the caller API: choose an ID, send a command, get its declared reply type. The first message creates or recovers the entity. The same calls work with local hosting and Cluster Sharding. Register and host the entity once at startup.
Define its behavior
Here is the Invoice behind those calls. Decide produces events and effects; Evolve computes the state from each persisted event. Issuing an invoice needs an answer from a recipient directory, so Decide records that verification started and issues a VerifyRecipient effect. The directory's answer comes back as a command, RecipientVerified or RecipientRejected, and a second arm finishes the job.
using InvoiceContext = DecisionContext<InvoiceState, InvoiceCommand, InvoiceEvent>;
public static class Invoice
{
public static readonly EntityDefinition<InvoiceState, InvoiceCommand, InvoiceEvent> Definition =
new(new EntityTypeName("invoices"), _ => new Draft(), Decide, Evolve);
public static Decision<InvoiceCommand, InvoiceEvent> Decide(
InvoiceState state, InvoiceCommand command, InvoiceContext ctx) =>
(state, command) switch
{
// Needs an outside answer: remember that we asked, then ask.
(Draft, IssueInvoice c) when c.Total > 0 =>
ctx.Persist(new VerificationStarted(c)).Execute(new VerifyRecipient(c.Recipient)),
// The answer arrives as a command. The request kept in state fixes the reply type.
(Verifying v, RecipientVerified) =>
ctx.Persist(new InvoiceIssued(v.Request.Total, v.Request.Recipient, ctx.UtcNow))
.Schedule("reminder", TimeSpan.FromDays(30), new SendReminder())
.Reply(v.Request, new InvoiceAccepted(ctx.EntityId)),
(Verifying v, RecipientRejected r) =>
ctx.Persist(new VerificationFailed(r.Reason)).Reply(v.Request, new InvoiceRejected(r.Reason)),
(_, RecipientVerified or RecipientRejected) => ctx.Ignore(),
(Issued s, RecordPayment p) when p.Amount == s.Total =>
ctx.Persist(new PaymentRecorded(p.Amount))
.CancelTimer("reminder")
.Reply(p, new PaymentAccepted()),
// A lost reminder mail is acceptable, so the light, unrecorded Run is enough.
(Issued, SendReminder) => ctx.None().Run<IInvoiceMailer>((mailer, ct) => mailer.RemindAsync(ct)),
(_, SendReminder) => ctx.Ignore(),
(_, IssueInvoice c) => ctx.None().Reply(c, new InvoiceRejected("Invalid invoice operation")),
(_, RecordPayment p) => ctx.None().Reply(p, new InvoiceRejected("Invalid invoice operation")),
};
public static InvoiceState Evolve(InvoiceState state, InvoiceEvent @event) =>
(state, @event) switch
{
(Draft, VerificationStarted e) => new Verifying(e.Request),
(Verifying, VerificationFailed) => new Draft(),
(Verifying, InvoiceIssued e) => new Issued(e.Total, e.Recipient),
(Issued s, PaymentRecorded) => new Paid(s.Total),
_ => throw new InvalidOperationException($"Cannot apply {@event} to {state}."),
};
}
VerifyRecipient is the effect: plain data, journaled in the same write as VerificationStarted. It says which command Decide gets when the directory gives no answer:
[AkkaSerializable(Manifest = "verify-recipient-v1")]
public sealed record VerifyRecipient([property: AkkaField(0)] string Recipient) : IInvoiceProtocol, IEffect<InvoiceCommand>
{
public InvoiceCommand GaveUp(WorkGaveUp g) => new RecipientRejected($"directory: {g.Reason}");
}
The only impure code is its handler, which Akka.Durable resolves from a fresh DI scope when the effect runs. The handler's second type argument says what kind of answer it produces, here a command that goes back through Decide:
public sealed class VerifyRecipientHandler(IRecipientDirectory directory)
: IEffectHandler<VerifyRecipient, InvoiceCommand>
{
public async Task<InvoiceCommand> HandleAsync(VerifyRecipient effect, EffectDelivery delivery, CancellationToken ct) =>
await directory.LookupAsync(effect.Recipient, ct) switch
{
Known => new RecipientVerified(),
Unknown u => new RecipientRejected(u.Reason),
};
}
// at startup, next to the other services
services.AddEffectHandler<VerifyRecipient, InvoiceCommand, VerifyRecipientHandler>();
The state, command, event, and reply declarations are in the guide. You write the domain functions and the handlers; Akka.Durable supplies the actor.
The calling surface is small: IEntityRef sends commands, and IDurableEntityRef adds state reads:
public interface IEntityRef<in TCommand>
{
EntityId Id { get; }
void Tell(TCommand command, IActorRef? sender = null);
Task<TReply> Ask<TReply>(IReplies<TCommand, TReply> command,
CancellationToken cancellationToken = default) where TReply : notnull;
}
public interface IDurableEntityRef<in TCommand, TState, TEvent> : IEntityRef<TCommand>
{
Task<StateSnapshot<TState>> GetStateAsync(CancellationToken cancellationToken = default);
}
Ask infers its reply type from the command. GetStateAsync returns the committed state and its journal sequence number. Both reference factories can be injected: use IEntityRefs<InvoiceCommand> for messaging, or IDurableEntityRefs<InvoiceCommand, InvoiceState, InvoiceEvent> for messaging plus state reads. Both are registered by AddDurableEntities(). The registry is keyed by command type, so each entity type must have its own command type.
You do not need to build an outbox. Akka.Durable has one.
ctx.Persist(new PaymentRecorded(p.Amount)).Execute(new PublishPayment(ctx.EntityId, p.Amount)); // in Decide
services.AddEffectHandler<PublishPayment, PublishPaymentHandler>(Retry.UntilAcknowledged(TimeSpan.FromSeconds(1), TimeSpan.FromMinutes(5)));
public sealed class PublishPaymentHandler(IBus bus) : IEffectHandler<PublishPayment> { /* ... */ }
PublishPayment is recorded in the same journal write as PaymentRecorded, and its handler runs at least once, after a crash too, until it returns without throwing; it can run more than once, so it must be safe to repeat.
See Effects for the other retry policies, and for Execute without a policy, which is attempted once and tells Decide how it ended. A workflow's work takes the same policies from the same registration: see Workflows.
Getting started
Install the .NET 11 SDK pinned in global.json, then run:
dotnet restore
dotnet build
dotnet test
The solution targets net11.0 and enables preview C# features (C# 15 unions are used throughout). Package versions are managed centrally; Akka.NET packages are pinned to 1.6.0-beta7 (Aaron.Akka.Reminders to 1.6.0-beta5).
| Package | Contents |
|---|---|
Aaron.Akka.Durable |
Entity definitions, decisions and effects, entity refs, the entity runtime, and Akka.Hosting integration. Everything is in the Akka.Durable namespace. |
Aaron.Akka.Durable.TestKit |
Test helpers built on Akka.Hosting.TestKit, in the Akka.Durable.TestKit namespace |
Guide
The rest of the documentation is in docs/, one topic per page. Read it in this order:
| Page | What it covers |
|---|---|
| State, commands, events, and replies | How to declare an entity's state, commands, events and replies, and what a decision can do. |
| Effects | Execute, the normal way to do outside work, retry policies (the outbox), and the light forms Run, Tell and Send. |
| Effects with outcomes | Effect handlers, answers and give-ups, for work whose result the entity decides on. |
| Talking to other entities | Send and Accepts, for one entity that drives another. |
| Starting a workflow from an entity | Uses, and Start, Notify and Cancel from a decision. |
| Serialization | What is serialized, and how to change stored types safely. |
| Hosting | Local and sharded hosting, passivation and shard count. |
| Sending commands | Entity refs, Ask and Tell, and entity IDs inside messages. |
| Reading state | State-aware refs, and what a state read sees. |
| Workflows | Finite processes that start once and end with an outcome: states, work, retry policies on work, the fact table, and workflow refs. |
| Workflow rules | Rules for writing a workflow that stays correct across restarts. |
| Testing | Decisions as plain functions, and the hosted TestKit. |
| Status and direction | What works today and what is not done yet. |
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net11.0 is compatible. |
-
net11.0
- Aaron.Akka.Durable (>= 0.1.0-alpha.5)
- Akka.Hosting.TestKit (>= 1.6.0-beta7)
- xunit.v3.assert (>= 4.0.3)
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 |
|---|---|---|
| 0.1.0-alpha.5 | 0 | 11/11/2026 |
| 0.1.0-alpha.4 | 35 | 11/11/2026 |
| 0.1.0-alpha.3 | 39 | 11/10/2026 |
| 0.1.0-alpha.2 | 43 | 11/10/2026 |
| 0.1.0-alpha.1 | 58 | 11/7/2026 |
Fifth alpha release of Akka.Durable. A workflow's work can now be retried by a policy, as an entity's effects are, and `Again` can wait before it repeats the work. Akka.Durable is still a proof of concept, not an official Akka.NET project.
* **Retry policies on workflow work.** Register the handler with a policy, for example `AddEffectHandler<ChargeCard, CheckoutFact, ChargeCardHandler>(Retry.Backoff(first, max, attempts))`. These are the same `Retry.Every`, `Retry.Backoff` and `Retry.UntilAcknowledged` as for entities, written once for each effect type. `ctx.Execute` takes no policy. A handler registered with a policy must be safe to repeat.
* **What a policy does.** A failed or timed-out attempt is attempted again after the policy's wait. Each attempt after the first is journaled before it runs, and the wait is a date in the workflow's reminder, so a restart keeps both, and a passivated workflow is woken. After a restart, an attempt that had no answer is attempted again. Between two attempts nothing is in flight, so facts from outside, cancels and timers are decided at once. A move to another state ends the retries, and a late answer of an earlier attempt is dropped.
* **`RetriesExhausted` for workflows.** When a limited policy runs out, the definition's `GaveUp` receives `GaveUpReason.RetriesExhausted`, with the number of attempts in `WorkGaveUp.Attempts` and the last failure in `Error`. `Retry.UntilAcknowledged` never gives up.
* **The idempotency key.** `EffectDelivery.Id` is the same on every attempt of one piece of work, and `Attempt` counts them. Give `delivery.Id.Value` to the other system as the idempotency key.
* **`ctx.Again(after)`.** Keeps the state and issues its work again after the delay. The delay survives a restart and wakes a passivated workflow. It shares the workflow's one reminder with the state's timers and the pending retries, and it does not move the timers. `ctx.Again()` is unchanged.
* **Held facts are decided before a finish.** A fact or a cancel that arrives while work is in flight is held, and the sender gets `Held`. When the work's answer leads to `Finish`, `Decide` now gets the held facts first, in the order they arrived, in the same state. A held fact that moves the workflow on wins, and the first finish does not happen. Otherwise the workflow finishes with the answer's outcome. Before, the held facts were dropped without a log entry. A workflow that holds no fact at its finish behaves as before.
* **A late answer of earlier work is dropped.** An answer to work of a state the workflow has left, or of an entry that `Again` replaced, is no longer decided or held as a fact from outside. It is logged at debug level. This was already the rule for work with a retry policy. A fact type that several pieces of work share can no longer be taken as the answer to the current work.
* **`IDurableJournalRecord`.** Every record that the library writes to a journal implements this public marker: the records of an entity's `Execute`, a workflow's events, and the snapshot envelope. A projection skips them with one type test.
**What you change from 0.1.0-alpha.4:** little. Work whose handler has no policy behaves as before: one attempt, then the give-up fact. A `Decide` that relied on a late answer of earlier work arriving as a fact no longer gets it: send that fact from outside with `Notify`, or keep the work in the state until it answers. A workflow that added a rest state before it finishes, only so that held facts would be decided, can remove that state. A projection that reads the journal can replace its own list of the library's record types with a test for `IDurableJournalRecord`. A journal written by this release cannot be read by 0.1.0-alpha.4 once a workflow has retried work, used `Again(after)`, or finished after held facts.
Not yet implemented: delivery of a workflow's outcome to the entity or workflow that started it, child workflows, a scenario test kit for workflows, state and event subscriptions, entity contracts and proxies, source generation, and snapshot retention tests.