---
id: TST-PFM-QRY-350
title: Platform scheduled delivery
kind: integration
product_area: platform
module: queries
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  rhythm-v2-docs: 99376625d3e7ac26936413cfc31a88fba6562464
repository: services-platform
files:
  - modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js
implements:
  - ATS-PFM-QRY-015-04
  - ATS-PFM-QRY-015-07
  - ATS-PFM-QRY-015-08
  - ATS-PFM-QRY-015-09
  - ATS-PFM-QRY-015-10
  - ATS-PFM-QRY-015-11
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: 'The suite’s database fixtures, controlled execution contexts and file-owned external dependency seams.'
evidence:
  - >-
    services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js
assertion_bindings:
  - scenario: ATS-PFM-QRY-015-04
    source:
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#fails
        the run with the sentence D4 gives, and sends nothing
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#fails
        the export access_lost
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#pauses
        the schedule with the reason, on the first such run
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#runs
        while the grant is active: the run succeeds, the export holds the rows and the e-mail is asked for
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#pauses
        the schedule with the reason once the grant is ended
    scope: assertions cited by the scenario
    provenance: test
  - scenario: ATS-PFM-QRY-015-07
    source:
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#records
        every recipient’s delivery: two submitted, the removed and the suspended user skipped with why
    scope: contributing assertions; the scenario combines multiple files
    provenance: test
  - scenario: ATS-PFM-QRY-015-08
    source:
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#asks
        for one e-mail per deliverable recipient, each under the key <run id>:<recipient id>
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#gives
        each recipient a personal link, signed for the export and that recipient, for seven days
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#submits
        nothing new when the same run is run again
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#does
        nothing for a redelivered message of the finished run
    scope: assertions cited by the scenario
    provenance: test
  - scenario: ATS-PFM-QRY-015-09
    source:
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#ends
        a skip-when-empty run skipped, its export holding no rows
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#sends
        no e-mail for it, and does send one for the schedule that sends empty results
    scope: contributing assertions; the scenario combines multiple files
    provenance: test
  - scenario: ATS-PFM-QRY-015-10
    source:
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#runs
        the criterion on the day of each run, in the tenant’s zone
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#records
        on each run’s export the day its parameter took
    scope: contributing assertions; the scenario combines multiple files
    provenance: test
  - scenario: ATS-PFM-QRY-015-11
    source:
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#succeeds
        on the redelivery, on its second attempt
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#e-mails
        each recipient once in all, and builds the file once
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#pauses
        the schedule after the fifth, saying why
      - >-
        services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js#fails
        each of those runs without retrying it
    scope: contributing assertions; the scenario combines multiple files
    provenance: test
fixture_seams:
  - >-
    services-platform:modules/queries/tests/integration/services/schedules/scheduled-delivery.integration.spec.js:174
---

# Platform scheduled delivery

## Verification Boundary

The file invokes its service or persistence boundary against local integration fixtures.

## What This Suite Proves

Its assertions check scheduled delivery. The assertion bindings identify the corresponding acceptance examples and retain their original test-title citations.

## What It Does Not Prove

Local execution does not establish deployed queue scheduling, every external provider response or a passing result at the pinned revision.

## Real Dependencies and Test Doubles

The integration fixture and any imported dependency seams define the environment. Database-oriented checks use PostgreSQL; file-owned transport, clock, provider or worker seams isolate the explicitly controlled boundary.

## Must Not Be Doubled

Keep the service or persistence operation whose behavior is asserted real. Database constraints and transactions cannot be replaced by fixture answers when they are the subject of the check.