---
id: WF-ACC-CLS-008
title: Erase the close history with the workspace
trigger: >-
  The workspace lifecycle caller requests deletion through the close-history
  participant.
product_area: accounting
module: close
revision: 1
status: draft
design_intent: proposed
implementation_evidence: observed
inference: []
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
implements:
  - CAP-ACC-CLS-016
crosses:
  - SVC-ACC-CLS-fiscal-close
idempotency: >-
  Each callback continues deleting the next available batch in dependency order.
  Repeated calls eventually report done when the participant’s tables are empty.
concurrency: >-
  Purge callbacks scope deletes to the selected workspace and declare
  configuration dependencies. These local guarantees do not establish the
  external scheduler or prevent concurrent new writes by themselves.
hops:
  - 'n': 1
    actor_or_service: Platform workspace lifecycle
    action: >-
      Declare configuration as a dependency so deletion can place close history
      before calendar records; external scheduling remains unverified.
    anchor: >-
      services-accounting:modules/maintenance/services/participants/fiscal-close-participant.ts:accountingFiscalCloseParticipant
    seam: sync
    on_failure: >-
      The module does not establish the lifecycle caller’s dispatch or retry
      policy.
    left_inconsistent: >-
      Previously completed deletion batches can remain while other tables await
      processing.
    observer: The lifecycle caller owns cross-participant progress.
    provenance: unknown
    source: FND-ACC-CLS-052
  - 'n': 2
    actor_or_service: Fiscal close purge participant
    action: >-
      Delete bounded batches in snapshot, close-job, reopen-job and run order;
      job children follow their roots by cascade.
    anchor: >-
      services-accounting:modules/maintenance/services/participants/fiscal-close-participant.ts:ACCOUNTING_FISCAL_CLOSE_PURGE_ORDER
    seam: sync
    on_failure: >-
      Rollback a failed batch; restricting references reject deletion while
      dependent records remain.
    left_inconsistent: >-
      Earlier successful batches remain deleted until later processing
      completes.
    observer: The callback and inventory report remaining rows.
    provenance: test
    source: >-
      services-accounting:modules/maintenance/tests/integration/services/participants/fiscal-close-participant.integration.spec.js#removes
      the snapshot first, then the close job, then the runs, one row a batch,
      and answers done
  - 'n': 3
    actor_or_service: Configuration purge participant (Books)
    action: >-
      Leave calendar deletion to its owning participant after the close records
      have gone.
    anchor: >-
      services-accounting:modules/maintenance/services/participants/configuration-participant.ts
    seam: queue
    on_failure: >-
      The database rejects calendar removal while close references remain;
      external delivery is not verified.
    left_inconsistent: A fully removed close history can precede unfinished calendar deletion.
    observer: The owning lifecycle participant reports its own outcome.
    provenance: test
    source: >-
      services-accounting:modules/maintenance/tests/integration/services/participants/fiscal-close-participant.integration.spec.js#lets
      the configuration’s purge remove the periods the runs named, to done
evidence:
  - >-
    services-accounting at f47cb263:
    modules/maintenance/services/participants/fiscal-close-participant.ts,
    purge-batches.ts, configuration-participant.ts;
    db/migrations/0064_fiscal_close_foundation.sql, 0065_fiscal_close_jobs.sql
    (restricting references).
controls: [TC-IAM-001, TC-IAM-005, TC-IAM-006, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-AZ-005, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-DAT-001, TC-DAT-004, TC-LOG-001, TC-LOG-002, TC-LOG-003, TC-AVL-001, TC-AVL-004, TC-MON-001, TC-MON-002, TC-MON-004, TC-PI-002, TC-PI-003, TC-PI-004, TC-PI-005]
---

# Erase the close history with the workspace

## What It Does

Workspace erasure removes close evidence and execution records before the calendar rows they reference. The participant declares its dependency on configuration and deletes its own records in bounded batches.

## The Flow

```mermaid
sequenceDiagram
  participant Caller as Lifecycle caller
  participant Purge as Close purge callback
  participant Data as Close tables
  Caller->>Purge: request bounded deletion
  Purge->>Data: snapshots, job roots, then runs
  Data-->>Purge: deleted rows
  Purge-->>Caller: remaining work or done
```

## When Something Fails

A failed delete batch rolls back that batch. Completed earlier batches stay deleted, and the next callback can continue. Foreign keys reject removal of a run while its snapshots or jobs remain. Platform owns participant ordering and retry delivery; only the declared dependency and module callback are verified here.

## Open Design Questions

The participant implementation establishes the local deletion order and workspace isolation. Platform evidence is still needed to verify orchestration and retries across participants.