---
id: ADR-ACC-CLS-002
title: Requests Persist Separately from Their Execution Jobs
product_area: accounting
module: close
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  A request commits one run with its first durable job before starting
  execution; linked retry jobs retain the same request and its outcome.
constrains:
  - DOM-ACC-CLS-003
  - SVC-ACC-CLS-fiscal-close
  - WF-ACC-CLS-001
  - WF-ACC-CLS-002
  - WF-ACC-CLS-003
  - STATE-ACC-CLS-002
origin: >-
  services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 74 (class A:
  close runs as a job with six steps; plan approved 2026-10-21);
  docs/fiscal-close/README.md#6.1 (the durable-jobs engine, not data jobs)
alternatives:
  - option: Perform closure within the HTTP handler.
    why_not: >-
      A lost or slow response would give staff no reliable execution view for
      recovery.
  - option: Use item-oriented data-job processing.
    why_not: >-
      The proposed close follows dependent tasks on one month rather than
      independent items.
  - option: Create another run for each recovery attempt.
    why_not: >-
      One finance request would become several business records and lose its
      continuous outcome history.
consequences:
  - >-
    Acceptance returns a run that can be polled independently of the original
    response.
  - The view combines attempts from the jobs within its read limit.
  - >-
    After-commit start failure is delegated to the reconciler helper while the
    run remains queued.
  - >-
    The route declares ordinary success with the run rather than asynchronous
    acceptance status.
supersedes: []
evidence:
  - >-
    services-accounting at f47cb263:
    modules/fiscal-close/services/jobs/fiscal-close-jobs.ts,
    close-run-actions.ts; aws/logic/fiscal-close.step-functions.ts.
---

# Requests Persist Separately from Their Execution Jobs

## Context

Finance staff need a persistent request they can inspect even when execution outlasts the HTTP call or needs recovery.

## Decision

Keep business request state on the run and execution state on durable jobs. Each retry adds a linked job and makes it the run’s current job.

## Alternatives Considered

Perform closure within the HTTP handler. A lost or slow response would give staff no reliable execution view for recovery.

Use item-oriented data-job processing. The proposed close follows dependent tasks on one month rather than independent items.

Create another run for each recovery attempt. One finance request would become several business records and lose its continuous outcome history.

## Consequences

Acceptance returns a run that can be polled independently of the original response. The view combines attempts from the jobs within its read limit. After-commit start failure is delegated to the reconciler helper while the run remains queued. The route declares ordinary success with the run rather than asynchronous acceptance status.