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.