--- id: ATS-PFM-QRY-019 scope: CAP-PFM-QRY-019 product_area: platform module: queries revision: 2 status: proposed approved_by: null approved_at: null source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f rhythm-v2-docs: 99376625d3e7ac26936413cfc31a88fba6562464 scenarios: - id: ATS-PFM-QRY-019-01 title: Available months are workspace-specific level: api proves: - BR-CAP-PFM-QRY-019-01 - INV-DOM-PFM-QRY-006-07 preconditions: One workspace has several snapshot periods and versions. steps: Read periods locally and as a user from another customer. expected: Local periods are distinct and ordered with their selected version; the other customer is refused. negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- 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#refuses another customer’s user the tenant’s periods - >- services-platform:modules/snapshots/tests/integration/services/persistence/snapshot-runs.queries.integration.spec.js#answers each period once, newest first, decided by the current version or else the highest one - >- services-platform:modules/snapshots/tests/integration/services/persistence/snapshot-runs.queries.integration.spec.js#reads only its own tenant: another tenant asks and gets its own one period - TST-PFM-QRY-467 - TST-PFM-QRY-473 provenance: test source: >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets the tenant’s own people read its periods category: permission binding_note: >- The cited suites contribute separate assertions. The complete combined example is not a single executable journey. - id: ATS-PFM-QRY-019-02 title: HQ snapshot reading differs from management level: api proves: - BR-CAP-PFM-QRY-019-02 preconditions: 'Administrator, support and customer contexts request snapshot work.' steps: List and request runs under each context. expected: 'HQ administration can do both, support can read only and customer contexts are refused.' negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets a Rhythm Administrator list the runs - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets a Support Representative read the runs, through the HQ reader policy - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#refuses a Support Representative a request, which is managing snapshots - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#refuses a customer’s own administrator every HQ route, which are staff-only - TST-PFM-QRY-467 provenance: test source: >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets a Rhythm Administrator list the runs category: permission - id: ATS-PFM-QRY-019-03 title: Period planning follows local month boundaries level: api proves: - BR-CAP-PFM-QRY-019-03 preconditions: Workspaces occupy different time zones. steps: Plan snapshots near month end. expected: Each run describes its workspace’s completed month. negative: false data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- 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#reads the disabled tenant's month in its own zone, August, and skips it with the policy's reason - TST-PFM-QRY-472 provenance: test source: >- 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 category: boundary - id: ATS-PFM-QRY-019-04 title: Eligibility and skips remain inspectable level: api proves: - BR-CAP-PFM-QRY-019-04 preconditions: 'Fixtures contain eligible, disabled and loading workspaces.' steps: Run planning for them. expected: Eligible work is planned and omitted periods retain explanatory skip state. negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#plans one run and skips two, passing over none - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#reads the disabled tenant's month in its own zone, August, and skips it with the policy's reason - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#skips the loading tenant, because half-loaded data is not history - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#leaves the skipped runs where they are: nothing admits a skipped run - TST-PFM-QRY-472 provenance: test source: >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#plans one run and skips two, passing over none category: rule - id: ATS-PFM-QRY-019-05 title: Reruns and back-fill allocate appropriate versions level: api proves: - BR-CAP-PFM-QRY-019-05 preconditions: A month has active work and a requested range contains gaps. steps: Request overlapping work and back-fill the range. expected: Active overlap returns 409 and eligible range periods receive distinct runs. negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- 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/e2e/snapshots.e2e.spec.js#refuses a second request for the same month while the first is under way (409) - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#back-fills one run for each month of the range - TST-PFM-QRY-467 provenance: test 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 category: concurrency - id: ATS-PFM-QRY-019-06 title: Failed validation preserves the preceding publication level: api proves: - BR-CAP-PFM-QRY-019-06 - INV-DOM-PFM-QRY-006-02 preconditions: Version one is published for a period using the suite’s small transaction-run self-test type. steps: 'Publish a rerun, then fail validation of another attempt.' expected: >- Version two becomes current, version one remains and the failing small run retains no generated rows or current-version change. This fixture does not establish rollback of earlier committed chunks. negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#publishes version 2 as the current one and keeps version 1, published and readable - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#fails the run with the checks that did not pass, and queues it for a retry - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#publishes nothing: none of its rows were kept, and version 2 is still the current one - TST-PFM-QRY-472 provenance: test source: >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#publishes version 2 as the current one and keeps version 1, published and readable category: failure binding_note: >- The small-run pipeline verifies transactional rollback. Chunked-run cleanup remains contradicted by the design examination finding. limits: - FND-PFM-QRY-049 - id: ATS-PFM-QRY-019-07 title: Ledger writers remain service-scoped level: api proves: - BR-CAP-PFM-QRY-019-07 - INV-DOM-PFM-QRY-006-03 preconditions: 'Accounting, Membership and Platform writer roles are available.' steps: 'Insert, update and delete rows belonging to each service.' expected: 'Roles write only their own rows, other owners are refused or unmatched, and deletion is denied.' negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- 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 - >- services-platform:modules/snapshots/tests/integration/db/snapshot-runs-accounting-writer.integration.spec.js#never deletes a run, not even its own tenant’s Accounting run: it holds no DELETE - >- services-platform:modules/snapshots/tests/integration/db/snapshot-runs.table.integration.spec.js#refuses Platform’s role a run of another owning service, even in its own tenant - TST-PFM-QRY-468 - TST-PFM-QRY-471 provenance: test source: >- 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 category: invariant binding_note: >- The cited suites contribute separate assertions. The complete combined example is not a single executable journey. - id: ATS-PFM-QRY-019-08 title: Active and current uniqueness remain independent level: api proves: - BR-CAP-PFM-QRY-019-08 - INV-DOM-PFM-QRY-006-01 preconditions: A period already has an active run and current publication. steps: 'Insert another active row, another current row and an inactive noncurrent row.' expected: The first two are rejected and the unrelated retained version is allowed. negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- 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:modules/snapshots/tests/integration/db/snapshot-runs.table.integration.spec.js#refuses a second current version of the same tenant, type and period - >- services-platform:modules/snapshots/tests/integration/db/snapshot-runs.table.integration.spec.js#accepts a second version that is neither active nor current, the negative control of both - TST-PFM-QRY-471 provenance: test source: >- 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 category: invariant - id: ATS-PFM-QRY-019-09 title: Retry intervals need explicit execution proof level: api proves: - BR-CAP-PFM-QRY-019-09 preconditions: A snapshot attempt repeatedly fails. steps: Allow its dispatcher to process all four attempts. expected: >- The proposed proof requires retries after fifteen minutes, one hour and four hours, then a final failed state and alarm accounting. negative: true data_needs: Prepare isolated fixtures for the states described here. bound_to: [] provenance: proposed source: 'services-platform:docs/snapshots/README.md#Configuration and the runbook' category: transition - id: ATS-PFM-QRY-019-10 title: Snapshot inputs identify supported work level: api proves: - BR-CAP-PFM-QRY-019-10 preconditions: A staff context can request snapshots. steps: 'Omit reason, use an invalid period or type and request a page above one thousand.' expected: Each request is rejected with its invalid input identified. negative: true data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#refuses a request with no reason, naming the field - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#refuses a period that is not a month - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#refuses a snapshot type this environment does not run - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#refuses a page of 1,001 runs, naming the limit - TST-PFM-QRY-467 provenance: test source: >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#refuses a request with no reason, naming the field category: validation - id: ATS-PFM-QRY-019-11 title: Workspace purge removes retained snapshot history level: api proves: - BR-CAP-PFM-QRY-019-11 - INV-DOM-PFM-QRY-006-04 preconditions: 'A workspace has multiple versions, runs and policy overrides.' steps: Purge it and repeat the purge. expected: All its retained resources disappear and the repeated operation removes nothing further. negative: false data_needs: Use the existing binding’s controlled fixture data. bound_to: - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#removes every snapshot row, run and override of the purged tenants, the run's version chain included - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#ends each tenant with a call that removed nothing, which is how the purge proves the tenant empty - TST-PFM-QRY-472 provenance: test source: >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#removes every snapshot row, run and override of the purged tenants, the run's version chain included category: transition - id: ATS-PFM-QRY-019-12 title: Search cleanup and snapshot cleanup respect the same workspace boundary category: interaction level: api exercises: - CAP-PFM-QRY-017 - CAP-PFM-QRY-019 proves: - BR-CAP-PFM-QRY-017-11 - BR-CAP-PFM-QRY-019-11 preconditions: Two workspaces have search resources and retained monthly history. steps: 'Delete one workspace, wait for its rebuild to settle and run the cleanup participants to completion.' expected: The deleted workspace has no indexed documents or retained snapshot versions; the control keeps both. negative: false data_needs: >- Use an isolated workspace with the described source records, access grants and a surviving control workspace. bound_to: [] provenance: proposed source: - >- services-platform:modules/quick-search/tests/integration/services/maintenance/tenant-participant.integration.spec.js#purges the tenant once the rebuild has settled, the job’s own three tables included - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#removes every snapshot row, run and override of the purged tenants, the run's version chain included - id: ATS-PFM-QRY-019-13 title: Workspace removal clears both kinds of retained history category: interaction level: api exercises: - CAP-PFM-QRY-018 - CAP-PFM-QRY-019 proves: - BR-CAP-PFM-QRY-018-08 - BR-CAP-PFM-QRY-019-11 preconditions: An isolated workspace has export settings and queued history plus multiple snapshot versions. steps: Run workspace deletion to completion and inspect both inventories. expected: Its package foundation records and snapshot history are removed; repeat cleanup reports nothing further. negative: false data_needs: >- Use an isolated workspace with the described source records, access grants and a surviving control workspace. bound_to: [] provenance: proposed source: - >- services-platform:modules/data-exports/tests/e2e/data-exports.e2e.spec.js#is answered 409 not_implemented for a download, until the generation job - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#removes every snapshot row, run and override of the purged tenants, the run's version chain included - id: ATS-PFM-QRY-019-14 title: Admission leaves excess planned work waiting category: concurrency level: api proves: - BR-CAP-PFM-QRY-019-12 - INV-DOM-PFM-QRY-006-06 preconditions: >- One owning service has five eligible planned runs, including two backfills, and its configured cap is four. steps: Dispatch admission concurrently twice and inspect admitted runs and attached attempt jobs. expected: >- At most four runs are admitted and at most one is a backfill; waiting runs remain planned and no run receives duplicate attempt work. negative: true data_needs: Create isolated periods and a controllable dispatcher for one owning service. bound_to: [] provenance: proposed source: 'services-platform:docs/snapshots/README.md#Configuration and the runbook' evidence: - 'Pinned reference: services-platform:docs/snapshots/README.md' - 'Pinned reference: services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js' - >- Pinned reference: services-platform:modules/snapshots/tests/integration/db/snapshot-runs-accounting-writer.integration.spec.js - >- Pinned reference: services-platform:modules/snapshots/tests/integration/db/snapshot-runs.table.integration.spec.js - >- Pinned reference: services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js - >- Pinned reference: services-platform:modules/snapshots/tests/integration/services/persistence/snapshot-runs.queries.integration.spec.js coverage: rule: covered transition: 'gap: FND-PFM-QRY-069' validation: covered permission: covered edge: 'gap: FND-PFM-QRY-069' failure: covered boundary: covered concurrency: covered invariant: 'gap: FND-PFM-QRY-069' interaction: covered coverage_findings: - FND-PFM-QRY-069 transition_obligations: - state: STATE-PFM-QRY-014 transition: 1 from: planned to: queued trigger: The owner dispatcher claims the planned run. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:claimRuns gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 2 from: queued to: running trigger: The job worker starts the queued run. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:startRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 3 from: running to: validating trigger: Generation enters final validation. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:beginValidation gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 4 from: validating to: published trigger: Final validation passes. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:publishRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 5 from: running to: failed trigger: Generation or exhausted job processing fails. source: 'services-platform:modules/snapshots/services/runs/snapshot-run-workflow.ts' gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 6 from: validating to: failed trigger: The final transaction fails validation. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-run-workflow.js:advanceSnapshotRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 7 from: failed to: queued trigger: The failed attempt reaches its next-attempt time. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-states.js (SNAPSHOT_RETRY_DELAYS_MINUTES) gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 8 from: planned to: cancelled trigger: 'Cancellation records workspace removal, policy or operator reason.' source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:cancelRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 9 from: running to: cancelled trigger: Cancellation occurs during generation. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:cancelRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 10 from: queued to: cancelled trigger: Cancellation occurs before the attempt starts. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:cancelRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 11 from: validating to: cancelled trigger: Cancellation occurs during validation. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:cancelRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 12 from: failed to: cancelled trigger: Cancellation replaces a pending retry. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:cancelRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 13 from: running to: running trigger: The worker resumes existing generation. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:startRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 14 from: validating to: validating trigger: The worker resumes existing validation. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:startRun gap: FND-PFM-QRY-069 - state: STATE-PFM-QRY-014 transition: 15 from: queued to: failed trigger: The job fails before generation starts. source: >- services-platform:node_modules/@rhythmsoftware/macroservice-snapshots/dist/snapshot-repository.js:failRun gap: FND-PFM-QRY-069 unproved_rules: [] --- # Preserve and inspect monthly data snapshots: Capability Test Specification ## Coverage | Rule | Scenario or Finding | |---|---| | `BR-CAP-PFM-QRY-019-01` | `ATS-PFM-QRY-019-01` | | `BR-CAP-PFM-QRY-019-02` | `ATS-PFM-QRY-019-02` | | `BR-CAP-PFM-QRY-019-03` | `ATS-PFM-QRY-019-03` | | `BR-CAP-PFM-QRY-019-04` | `ATS-PFM-QRY-019-04` | | `BR-CAP-PFM-QRY-019-05` | `ATS-PFM-QRY-019-05` | | `BR-CAP-PFM-QRY-019-06` | `ATS-PFM-QRY-019-06` | | `BR-CAP-PFM-QRY-019-07` | `ATS-PFM-QRY-019-07` | | `BR-CAP-PFM-QRY-019-08` | `ATS-PFM-QRY-019-08` | | `BR-CAP-PFM-QRY-019-09` | `ATS-PFM-QRY-019-09` | | `BR-CAP-PFM-QRY-019-10` | `ATS-PFM-QRY-019-10` | | `BR-CAP-PFM-QRY-019-11` | `ATS-PFM-QRY-019-11`, `ATS-PFM-QRY-019-12`, `ATS-PFM-QRY-019-13` | ## Interactions With Related Capabilities The combined examples change a source, its audience or its retained state before checking the dependent outcome. Unbound examples remain proposed, and the coverage finding retains design obligations that these examples do not establish. | Related Capability | Scenario | |---|---| | `CAP-PFM-QRY-017` | `ATS-PFM-QRY-019-12` | | `CAP-PFM-QRY-018` | `ATS-PFM-QRY-019-13` | ## Evidence and Binding Limits The source revisions pin the inspected assertions. A test binding identifies written assertions, and does not establish a successful run or approval of the expected behavior.