getOperation

Recover any durable operation by its request identity.

GroupDurable operation recovery

RuntimesTypeScript browser/server, React client adapter, Python/Go server

Updated2026-09-15

Status

Proposed target SDK behavior for implementation. It is not an available activity service or an indefinite idempotency guarantee.

One request identity, one recorded outcome. The backend binds the request ID to immutable operation material the moment it is accepted. Authorization proof accumulates alongside that record instead of changing it, so adding a valid response never creates a changed-material conflict. Repeating the same ID with the same material converges on the recorded result; repeating it with different material conflicts and creates no additional effect.

Business action#

Recover the durable disposition and meaningful result of a prior mutation by its stable requestId, including create, update, sign, send, import, export, policy and recovery actions.

Proposed call#

getOperation(
  input: GetOperationInput,
  options?: CallOptions,
): Promise<OperationResult>

TypeScript uses requestId and optional authorization. OperationResult is a discriminated union keyed by kind and state, so result fields are available only for the matching operation/state. undefined omits authorization; null does not submit an empty response.

async def get_operation(
    input: GetOperationInput,
    *,
    options: CallOptions | None = None,
) -> OperationResult: ...

Python uses request_id and an authorization field whose default is UNSET. OperationResult is a typed union with string-valued kind and state enums; None is not an authorization submission.

GetOperation(
    ctx context.Context,
    input *GetOperationInput,
) (*OperationResult, error)

Go uses RequestID plus a presence-aware Authorization field, with stable JSON names. OperationResult exposes named string Kind and State values and a typed result variant; callers must not infer success from a non-nil envelope alone.

The request identity is required. With no authorization response this is a pure, effect-free read. When the original operation remains requiresAction, the caller may supply a response obtained from the application handler; it must bind the original immutable operation material and cannot replace that material.

Result#

Returns operation kind, request ID, payload identity, state (requiresAction, progressing, succeeded, denied, expired, failed, or unknown), meaningful typed result when available, safe error, agreement progress when applicable, and identity-retention expiry when known.

One ordinary business call may internally await within its deadline. This business-level method prevents applications from having to implement a repeated status loop. The approval catalog exposes human or multi-party review while this method remains the execution-result and restart-recovery facade.

Effects and failures#

A call without authorization is effect-free. A call with authorization is an explicit stateful continuation that may accumulate the bound response and advance only the already-recorded original logical operation under the owning backend's atomic contract; it is not a new action. A response is submitted either automatically by the configured handler path or explicitly here, never both. Same request ID with different immutable material always conflicts. Missing or expired identity is explicit and never permission to repeat a financial or disclosure effect. Foreign requests are non-disclosing.

Acceptance#

Positive: after process restart, the integrator can recover the same operation/result and, when action is still required, submit authorization bound to the original operation.
Negative: continuation cannot mutate payload or create another logical effect; a pure read cannot advance state; missing/expired identity cannot become safe-to-retry.

See SDK model and business stories and Approvals.