Monthly history connects workspace eligibility and local calendar periods to publication and readable retained versions. The suite follows planning, reruns, failed validation and cleanup. Its small self-test case establishes a bounded publication result; larger chunked generators retain their separate cleanup finding.
Workspace removal joins historical cleanup to search-resource cleanup while a surviving workspace supplies the control. Within snapshots, the lifecycle case publishes a replacement and then fails the next attempt, checking which version remains selected. Permission and regression cases distinguish read access, run management and the uniqueness of active and published versions.
Eligible, disabled and loading workspaces occupy different time zones.
Steps
Plan the completed months, admit eligible work, publish it and read periods from each workspace.
Expected
Eligible publication becomes the selected version while skipped months preserve their reasons and local period boundaries.
Data
Use an isolated workspace, named fixture records and the caller grants described by the prerequisites.
Source
services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets the tenant’s own people read its periods,services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#plans the eligible tenant's September in its own zone, as version 1 of a captured, scheduled run,services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#plans one run and skips two, passing over none
02Historical periods coexist with current record lookupinteractionproposed
The local user-status-counts self-test has a published first version and real database fixtures.
Steps
Add a user and publish a second version, corrupt the next attempt’s inserted counts through the test trigger, run final validation and read the retained period and versions.
Expected
The second version remains current and readable, the first stays retained, and the failed small attempt publishes no rows; the assertion does not cover committed chunks from other generators.
Data
Use an isolated workspace, named fixture records and the caller grants described by the prerequisites.
Support, HQ administration and customer contexts can attempt their respective snapshot operations.
Steps
List periods and runs, request new runs as support and a customer, and write a ledger row under another service’s role.
Expected
Read access does not grant management, customer callers do not reach HQ and service writers cannot change another owner’s ledger.
Data
Use an isolated workspace, named fixture records and the caller grants described by the prerequisites.
Source
services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets the tenant’s own people read its periods,services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets a Rhythm Administrator list the runs,services-platform:modules/snapshots/tests/integration/db/snapshot-runs-accounting-writer.integration.spec.js#refuses a run whose owner_service is another service’s, in its own tenant
05Repeated planning and reruns keep independent uniquenessregressionnegativeproposed
A period has a published version and another version is actively running.
Steps
Repeat planning, request overlapping work and try a second current or active row while retaining an inactive version.
Expected
Duplicate active or current versions are refused; retained inactive history is allowed and dispatcher admission remains bounded.
Data
Use an isolated workspace, named fixture records and the caller grants described by the prerequisites.
Source
services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#plans a manual run as version 1 of a captured run, for the dispatcher to start,services-platform:modules/snapshots/tests/integration/db/snapshot-runs.table.integration.spec.js#refuses a second active run of the same tenant, type and period,services-platform:docs/snapshots/README.md#Configuration and the runbook