Close run lifecycle

The Lifecycle

Transitions Explained

Acceptance saves one queued request with its job. Locking starts it, and finalization records success. A queued failure is represented to callers as failed although the writer moves it through running in the same failure transaction.

A failed run can resume only while it retains its month. Retry adds a linked job and clears the failure. A released month needs a new request. Cancellation is available through the service for queued or failed runs, subject to the committed revenue checks; the console exposes it only after failure.

What Cannot Happen

Succeeded and cancelled runs have no outgoing writer transitions. The recovery service also rejects cancellation during running work and retries after release. Only the newest job is intended to settle failure, but the pre-lock run read needs concurrency verification to establish that intent under a race.

Concurrency and Timing

The period row is shared by changing tasks and recovery. Retry and cancellation refresh the run after acquiring it; failure handling does not. Jobs left queued and retained failures have no module expiry. A successful close stops active polling even while its final calendar-maintenance task remains unfinished.