Retry Policy
This page is part of the documentation for Orleans.Lattice 9.9.0 (release line 9.9), built 2026-10-04. It is also published as markdown, with every table and list, at README.md, and llms.txt lists every page.What it shows
Storage faults are sometimes transient (a throttle, a brief network blip). This
sample wraps a write in BoundedExponentialRetryPolicy and pairs it with a
LatticeIdempotencyContext scope, so the operation is retried under a stable
idempotency key. A simulated transient fault fails the first two attempts
before the write is issued, and the third succeeds. Every attempt carries the
same idempotency key, so had a failed attempt already landed its write, the
retry would collapse to a single logical mutation rather than apply twice.
Run it
dotnet run --project samples/RetryPolicy
Expected output
Silo starting... ready.
== Retrying a write that fails twice under a simulated transient fault ==
attempt #1...
attempt #2...
attempt #3...
attempt succeeded - write committed.
tree['orders/42'] = shipped (after 3 attempts)
Done. The operation survived transient faults and the retried write
collapsed to a single mutation under one idempotency key.
When to use
- Wrapping writes that can hit transient backend faults (throttling, timeouts) where a bounded, backing-off retry turns a blip into a success.
- Any retried single-key mutation or range delete that must stay exactly-once:
supply a caller-owned idempotency key so a replay does not double-apply. The
batch, atomic, and bulk-load entry points (
SetManyAsync,SetManyAtomicAsync,BulkLoadAsync, ...) do not take the ambient key.
When not to use
- Deterministic, non-transient failures (bad input, auth). Retrying just delays the inevitable error - let it surface. Classify which exceptions are retryable via the policy's classifier.