Durable operations and reconciliation#
Workflow separates the intent to execute an operation from transport acceptance, participant acceptance and business completion. These facts may become visible at different times. A lost response does not establish whether the remote effect happened.
ServiceCommand and OperationReceipt represent the documented command and receipt boundaries. A command binds its tenant, target, operation, attempt, immutable input and relevant business lineage. A participant persists the semantic command digest so repeated delivery cannot silently change the requested work.
Commit boundaries#
| Boundary | Durable fact |
|---|---|
| Workflow transition | Node state, history, operation/attempt and dispatch intent commit together |
| Broker confirmation | The configured broker accepted the publication under its transport policy |
| Participant acceptance | The executor retained a recoverable operation and its identity |
| Participant completion | The business effect and terminal receipt are authoritative |
| Workflow receipt application | A validated result and successor intent commit once |
Each owner controls its own transaction. No cross-service database transaction or global exactly-once guarantee is implied. A database worker lease prevents stale engine commits, but it cannot stop an already-issued remote effect. The participant's idempotency and reconciliation contract remains necessary.
Idempotency and identity#
The same command identity with the same semantic input returns the existing receipt. Reusing that identity with changed input conflicts. Retry-varying tracing headers and transport delivery tags do not define semantic identity.
The documented ExecutorRoute is trusted deployment configuration, not a URL supplied by a process author. Instances pin the route and binding used for their operations. New configuration cannot silently redirect existing work to another owner.
ApplyReceiptAsync validates the receipt/result schema and the exact tenant, owner, principal, operation, attempt and request identity. Older owner revisions cannot roll state backward. A repeated owner revision with changed content is rejected. Successful application records the result and next-step intent atomically.
Unknown outcomes#
A timeout can produce OutcomeUnknown. Workflow suspends progression and pauses command dispatch while retaining custody records and obligations. It does not interpret timeout as permission to create a new operation.
The recovery action reconcile records a query intent, represented as ReconcilePending, against the pinned executor. Query results pass through the same receipt validation path as ordinary responses. A null query result means no receipt was returned; it is not proof that no effect occurred.
The action retry-safe requires authoritative RetryWaiting with effect none. It retains the operation/input identity while creating the allowed new attempt and command. Unknown effects cannot become success through an operator assertion or blind replay.
Cancellation races#
Cancellation is a request to settle work consistently with the executor's durable state. Work with an unresolved effect remains Cancelling until authoritative evidence resolves it. A success that wins the race remains Succeeded on the operation, even when cancellation prevents further successors.
Cancellation before acceptance also requires a durable record. Otherwise a delayed command could arrive after an apparently successful cancellation and still execute. The same principle applies to an authorized cancellation of a start request before an instance exists.
Recovery and restore#
The runtime's IExecutorAdapter boundary defines Submit, Query and Cancel against the same immutable command and pinned route. Recovery preserves that identity and retains current authorization checks. Operators use controlled recovery commands rather than editing runtime rows directly.
Before restoring a database, disable effect dispatch. Reconcile source journals, owner receipts and task state before resuming. A restored engine can predate an effect that already committed elsewhere. Receipt retention and deduplication history must cover every permitted retry, replay and restore horizon.
The documented reference establishes these semantics for its selected implementation and acceptance scope. Operational throughput, availability and recovery objectives require separate deployment evidence. See events and choreography for subscriber custody and participant implementation for transport boundaries.