Recalculation Run

What It Models

A recalculation run represents staff’s request to revisit existing placements under saved coverage. It provides persistent progress and an outcome while processing continues across requests and queue deliveries. It is separate from the file-import engine’s jobs.

Identity and Attributes

The service allocates an identifier and begins with running status in the contact phase. The cursor and counts advance with committed batches. After contacts, processing walks organizations and then completes. A private starting generation supports the policy’s outstanding-work flag, and a continuation counter requests further delivery.

Relationships

Each batch reads current policy rather than a frozen copy. Changes made during processing can affect later records while leaving another recalculation needed. Regional values are written through Entities persistence; the run stores progress rather than record copies.

Invariants

The unique running-run constraint prevents parallel runs in one workspace. Workers take turns on the run lock and commit progress with each batch. Failed batches roll back while earlier batches remain. Failure settlement stores a redacted reason when possible and attempts terminal status on the final queue delivery.

How It Is Stored and Shared

Regions owns runs and their regional continuation stream. Insert and continuation events reach the runner; ordinary progress does not start another worker. Workspace exports withhold this operational bookkeeping, and reset or purge removes it.

Open Design Questions

Regional routes provide no cancellation or direct repair of a stuck run. If terminal failure settlement fails, a dead-lettered message can leave the run running. An in-request failure can also report a failed start even though a run exists, and the console does not restore failed historical runs.