Newest first, grouped by year. Search or filter by topic.
Trill's ad-publication saga implements Compensating Action in five overrides and can reach none of them - the rejection events it subscribes to carry no correlating id, their handlers return Task.CompletedTask, and no handler ever throws.
OrderMaker drives a whole order through a Chronicle saga and reports its progress in a single RabbitMQ header - stamped on every publish, forwarded by seven copied MessageBrokers, read back by Operations, and backed by a saga store that forgets everything on restart.
A stateful DShop saga remembers when a customer signed up and grants a discount only if their first order lands within 24 hours - a genuinely stateful process manager whose reward turns out to be a Console.WriteLine. Part 7 of Nine Services and a Message Bus.
Operations drives an order from created to approved across three services, and rolls it back when a step fails - a textbook process manager with compensation, read from the real Chronicle-backed source. Part 6 of Nine Services and a Message Bus.
Chronicle ships two persistence integrations, and reading them against the contract is a masterclass in provider sharp edges: a Redis key built from Type.GetHashCode() that changes on every restart, a Mongo delete-then-insert, and messages that may not survive the round trip.
Eight parts of source-reading later, the honest retrospective. What Chronicle gets right, the timeout-shaped hole at its centre, how it stacks up against MassTransit and NServiceBus and durable execution - and the cases where a status column beats every saga framework ever written.
Chronicle's persistence surface is two interfaces - a state repository and an append-only log - and the defaults behind AddChronicle() are two Lists. What the contracts really demand, why the in-memory implementations are sharper than they look, and how to write a provider that holds up.
When a Chronicle saga rejects, the saga log is replayed backwards and every handled message gets its CompensateAsync called. Tracing both rejection paths through the source reveals a surprise - only one of them actually compensates - plus a ForEach that never awaits.
Seeker, initializer, processor, post-processor - Chronicle's whole runtime is four internal classes you can read in ten minutes. A source walk through the pipeline, including the gate that drops messages, the finally block that always persists, and the state that isn't as final as it looks.
services.AddChronicle() registers sagas you never mentioned, and one ProcessAsync call can run five of them in parallel. Inside Chronicle's Scrutor scan, the seeker's dedupe trick, and the ref-counted lock that serializes each saga id.
Correlation is the part of the saga pattern that fails silently. SagaId, SagaContext, the Empty-context trap that starts a new saga per message, and the one-method override that routes messages by their own content.
Split one database into five services and the transaction you deleted does not disappear - it goes feral. On sagas, compensation, process managers, and Chronicle, the small open-source .NET library this series reads line by line.
Chronicle's entire programming model is Saga<TData>, ISagaStartAction, and ISagaAction. Building a full order-fulfilment saga to learn what Complete() promises, what Reject() actually does, and why a saga can have more than one beginning.
