Compliance reprocess run
Purpose
A compliance reprocess revisits existing organizations after policy administration or a request to refresh assessments. The request cannot realistically hold one response open for every organization in a large association. A durable run instead retains its scan position, counts and outcome while bounded workers process the remaining organizations.
Our reading is that the explicit run states make partial progress distinguishable from success. A completed run records that its scan finished; a failed run can leave earlier organizations recalculated and later ones untouched. Neither state establishes delivery of notices created during the scan.
Ownership and Authority
An actor holding organization update authority starts reprocessing. The route returns a message and organization count after recording the request or finding an existing running run. Workers own cursor advancement, continuation and final outcome; there is no staff action that directly sets completed to make an unfinished scan disappear.
The queue identifies a final receive, and the worker uses that signal when recording terminal failure. No model recommends or executes these transitions. Request permission does not grant access to unrestricted processing controls or turn a run into a fixed policy snapshot.
The Lifecycle
States
requested
A reprocess has been requested but not persisted. Entry requires this condition: An authorized request has reached start composition but no run is persisted yet. Available behavior is Create a run or return the existing running run.. This is a request stage rather than a durable saved status.
running
A stored run scans organization identities in ordered batches from its committed cursor. Entry requires this condition: A run row has been inserted and remains eligible for worker processing. Available behavior is Resume uncommitted work; append continuation; record retryable failure.. Counts and cursor reflect committed batches rather than work merely attempted.
completed
The scan reached its end and retains examined and recalculated counts plus finish time. Entry requires this condition: The locked batch finds no further organization beyond its scan position. Available behavior is Inspect the final run; request a separate future run.. Examined and recalculated totals and finish time remain recorded. This row’s lifecycle ends here; a new request or new record is separate work.
failed
The final permitted failing delivery marked the run terminal and retained a redacted failure reason. Entry requires this condition: A failing final receive records terminal status. Available behavior is Inspect the redacted reason; request another run.. The workspace may be partially reprocessed; redrive does not reopen this run. This row’s lifecycle ends here; a new request or new record is separate work.
Transitions Explained
requested → running
An authorized organization updater starts this change when the following occurs: Request compliance reprocessing. The transition checks this boundary: Organization update permission; return an existing running run rather than creating a second one. The accompanying work is insert the run; capture an event that starts its worker; nudge event dispatch. Run storage records cursor, examined and recalculated counts, continuation and completion or redacted failure information. Each organization changed during a batch has its own attributed revision; the run is not an organization revision.
running → running
The reprocess worker starts this change when the following occurs: Continue after the worker budget or a retryable batch failure. The transition checks this boundary: The persisted run must still be running. The accompanying work is commit cursor and counts with each batch; increase continuation counter for another worker; record failure reason and clear it after success. Run storage records cursor, examined and recalculated counts, continuation and completion or redacted failure information. Each organization changed during a batch has its own attributed revision; the run is not an organization revision.
running → completed
The reprocess worker starts this change when the following occurs: Finish the batch that exhausts the scan. The transition checks this boundary: No organization remains after the cursor. The accompanying work is store completion status and finish time. Run storage records cursor, examined and recalculated counts, continuation and completion or redacted failure information. Each organization changed during a batch has its own attributed revision; the run is not an organization revision.
running → failed
The reprocess worker starts this change when the following occurs: Fail on the final permitted message receive. The transition checks this boundary: The consumer identifies this delivery as its final attempt. The accompanying work is mark run failed with redacted reason; throw so queue dead-letter policy applies. Run storage records cursor, examined and recalculated counts, continuation and completion or redacted failure information. Each organization changed during a batch has its own attributed revision; the run is not an organization revision.
What Cannot Happen
A worker presented with a completed run returns its existing outcome without restarting it. A new authorized request creates a separate run.
A redriven message naming a failed run is also skipped. The supported recovery is another reprocess request, so an operator must not treat dead-letter redrive as a resume command.
Permissions by State
The state rows reference grants from the CRM authorization model. Read access is distinct from mutation, and history requires the corresponding history and read checks. Administrator and Power User hold administrative record actions; ordinary Standard User grants include applicable read and update operations, while Read Only grants do not authorize edits.
Organization update is the permission for requesting a reprocess. Workers use their internal execution context rather than requiring the requesting user to remain online. Completed and failed runs cannot be restarted by changing the permission.
Concurrency and Timing
The database admits only one running run for a workspace. Each batch locks that run and the selected organizations and commits recalculation with cursor and counts. Duplicate workers serialize instead of independently replaying completed batches. A request racing another start can receive the already-running run.
The consumer normally takes twenty-five organizations per batch within forty seconds. If time remains, it continues; otherwise a continuation change asks for another delivery. Earlier batches survive a later failure. Policy edits can affect later batches because the run does not pin a workspace-wide version of type configuration.
Invariants
Our reading is that one running scan and one locked cursor prevent two workers from claiming incompatible progress for the same request. A committed batch includes its organizations and progress together; attempted work cannot advance the cursor while leaving those assessments unchanged. Earlier batches remain after a later failure, which is why failed describes a partial outcome rather than a rollback. Terminal runs stay terminal under duplicate delivery. Recovery creates another request instead of silently reopening the old run.