Orleans

Microsoft Orleans

Diagnostic Output Budget

Keep native test progress and ANSI visible; use the detected runner's supported flags (--progress on --ansi on for MTP/TUnit), not MTP switches on VSTest. Keep console logs at Warning or higher and one concise final summary. Do not replay progress redraws, successful-test output, or Information/Debug/Trace logs into model context. On failure/crash, show only the failing test/resource, root error, and relevant stack frames; deduplicate and cap each diagnostic response at 80 lines / 8 KiB. Never dump entire console/host/browser logs, HTML, TRX, or crash artifacts. Keep necessary artifacts size-bounded outside context, link them, and inspect exact bounded excerpts. Preserve the runner exit code through capture/filtering; disclose truncation. Silence alone does not establish a hang.

Start With Purpose

Do not begin with an Orleans API. First state:

1. the business identity that owns the behavior;
2. the invariant and what must survive activation or cluster failure;
3. the required consistency, query shape, acknowledgement, durability, replay, fan-out, and timing.

Then select the smallest Orleans primitive whose guarantees match those requirements. Reject Orleans when the problem is primarily shared-memory computation, a finite batch, relational querying, or global coordination with few independent entities.

Inspect package versions for version-sensitive work. Orleans 10.3.1 ships Microsoft.Orleans.DurableJobs* and Microsoft.Orleans.Journaling* as 10.3.1-alpha.1; treat them as experimental until that status changes.

Orleans 10.3 makes Newtonsoft storage enforce the type allow-list, changes RPC telemetry keys, and requires custom grain-context activators to apply configurators before construction. Prefer generated/allowed types over permissive JSON and update affected tests, dashboards, and activators together. 10.3.1 services analyzer contract identities and documents placement hints.

Mental Model

• A grain is a virtual actor with stable identity, behavior, and optional state, not a process, row, DTO, controller, or background job.
• A grain reference is a location-transparent address. Getting a reference does not create a durable record or prove that an activation exists.
• An activation is an ephemeral in-memory execution instance. Orleans creates, places, moves, deactivates, and recreates it. Never equate activation lifetime with entity lifetime.
• A normal grain has at most one activation in the cluster by default and processes turns one at a time. This makes the grain a natural owner of per-identity invariants.
• A silo hosts activations. Silos form a cluster; external clients or a co-hosted IGrainFactory call grains.
• Calls are asynchronous messages even when they look like C# method calls. Network failure, timeout, serialization, retries, and duplicate side effects still matter.
• A grain can model a digital twin when its identity and behavior map to a real or domain entity; that is a use case, not every grain's definition.
• Orleans gives logical ownership and turn-based execution. It does not make external side effects transactional, turn arbitrary data into a queryable database, or provide exactly-once execution by default.

Workflow

1. Inspect the solution, Orleans version, hosting topology, grain interfaces, providers, and tests.
2. Identify domain identities and invariants. Prefer many independent, bounded entities over global coordinator grains.
3. Choose state, communication, and time-based work from the tables below.
4. Keep default non-reentrant scheduling and placement until a measured requirement justifies a change.
5. Configure providers independently and test the failure model the design depends on.

Choose the State Owner

Grain State Versus a Database

Use grain state for bounded current state and per-identity invariants. Use a database/read model for joins, search, reporting, bulk work, history, shared access, or an external system of record. When using both, define one authority per field and recovery rules.

Never query or mutate another grain's persistence record behind the grain, or expose provider storage as the public query model merely because it uses SQL/Cosmos/Redis. Before using transactions, try one bounded grain owner; use a saga for external effects or long waits. Read references/persistence-api.md for the full boundary.

Choose Communication

Prefer a direct call unless decoupling is a requirement. Do not use a stream merely to avoid calling a known target. Do not use broadcast channels for commands, money movement, audit events, or anything that must be replayed. Do not use observers as a durable event bus.

When adding retries, make side effects idempotent. Default Orleans calls are at-most-once only while neither the runtime nor application retries. Retried calls can arrive more than once, and Orleans does not durably deduplicate them for the application.