Documentation / Transactions

Selected command route

A selected command route is an opt-in path for commands whose event writes and related handoffs must close together. It binds one authenticated operation to one root actor, a current deployment route, a complete event plan, and a capable store. Ordinary actor commands remain available; installing an adapter does not select this path.

On this page

A selected command binds ingress identity, route authority, a closed event plan, and an atomic store receipt.

From ingress to completion

  1. Authenticate the caller and authorize the command, actor, and route at ingress. The host supplies the current principal; message metadata alone is not authority.
  2. Create or verify a stable operation ID and canonical request identity. TrustedAtomicCommandIngressAdapter and TrustedAtomicCommandIdentityAuthority describe this boundary.
  3. Acquire the selected route lease and verify the current deployment epoch and fingerprint. Admission can reject a stale silo or an unreviewed actor/handler registration.
  4. Plan the root event and any supported causal subscriber events while handlers remain free of external effects. Freeze a closed participant set before storage.
  5. Commit with the route fence and expected versions. Return the durable completion receipt only after every required write and projection handoff commits.

The memory-only path has additional contextual contracts (MemoryOnlySelectedCommandContext and IMemoryOnlyContextualAtomicEventTransactionStore). “Memory-only” describes precommit planning, not disposable persistence. A failed planner cannot be recovered by replaying a side effect.

Route selection checklist

Select the route only after reviewing the actor and subscriber inventory, event serialization, store capabilities, recovery policy, provider idempotency, and retention window. Pin the selected deployment and keep the route fence current across promotion or rollback. Atomic commit, route authority, and recovery provide the individual contracts.

Example: Bind a command identity

After authenticating and authorizing the caller, issue a claim from canonical command bytes. Keep the server key in trusted host configuration and reuse the same operationId for retries.

public static TrustedAtomicCommandIdentityClaim IssueIdentity(
    byte[] serverKey, Guid operationId, byte[] canonicalCommand) =>
    TrustedAtomicCommandIdentityAuthority.Issue(serverKey, operationId,
        "user-42", "CounterActor/42", nameof(Increment), canonicalCommand);