Lifecycle
Lifecycle stateと遷移、不変条件、Terminal Outcomeの意味を説明する。
BlackOpsはInlineとDeferredを同じLifecycle Modelで記録します。ApplicationはOperation IDを相関Keyとして受付からTerminal Stateまで追跡できます。Outcome RecordはDeferred完了時だけ保存し、Inlineでは作成しません。
共通Lifecycle
正常完了するOperationはReceived、Running、Finalizing、Completedの順に進みます。DeferredだけはDurable受付後にAcceptedを経由します。
正常完了
業務拒否
失敗とRetry
失敗の図で再掲するSupervisingやFailedは同じ論理状態です。 独立した経路同士を順番に実行する意味ではありません。 FinalizingとSupervisingはLifecycleの処理段階であり、公開Status APIの値ではありません。
| 経路 | 状態遷移 |
|---|---|
| Inline成功 | Received → Running → Finalizing → Completed |
| Deferred成功 | Received → Accepted → Running → Finalizing → Completed |
| 業務拒否 | ReceivedまたはRunning → Rejected |
| Retry | Running → Supervising → Retry Scheduled → Running |
| 最終失敗 | Running → Supervising → Failed |
| Deferred隔離 | Running → Supervising → Dead Letter |
InlineはAcceptedを通らず、受付元のProcessでAttemptを開始します。DeferredだけがDurable受付後にAcceptedとなり、別ProcessのWorkerがClaimしてAttemptを開始します。Completed、Rejected、Failed、Dead LetterはTerminalであり、新しいLifecycle EventやHandler実行へ進みません。
Rejected
OperationRejectedExceptionは予期された業務拒否です。FrameworkはRejected ResultとTerminal Lifecycleへ変換します。Validation、Authorization、Not Found、Conflict、Business Ruleを安定したCategory／Codeで表現します。
RetryとFailure
Retryable ExceptionはSupervision Policyに従いattempt.failedとattempt.retry_scheduledを記録します。次のWorker Attemptが同じOperationを再Claimします。Retry上限を超えた処理はFailed／Dead Letterへ進みます。
通常のException、Worker Interrupt、Claim Lossは業務拒否として扱いません。Lease、Heartbeat、Fencing Tokenにより、古いWorkerが成功を確定しないようにします。
Outcome
DeferredのCompletedだけがTyped Outcomeを保存します。InlineはOutcome Recordを作成せず、HTTPではResponseへ、Operation用CLIでは--json指定時の完了JSONへOutcomeを返します。Rejected、Failed、Retry Scheduled、Dead Letter、Claim LostはOutcome Recordを作成しません。詳細はOutcomeを参照してください。
JournalとOutcomeは別々の保持期間を設定できます。Operation単位のHoldと安全なPurgeについてはRetentionを参照してください。
Lifecycle EventのObserved JSONL、Canonical／Observedの境界、Observer ReplayはJournalで確認できます。
仕組みを理解したらInstallからApplicationを作成します。
次にContextの伝播を読む
状態遷移に付随するID、Actor、Tenant、Attemptは、Execution Contextで確認します。