---
id: TST-PFM-NOT-074
title: deliver delivery
kind: integration
product_area: platform
module: notifications
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js
implements:
  - ATS-PFM-NOT-006-08
  - ATS-PFM-NOT-007-04
  - ATS-PFM-NOT-007-05
  - ATS-PFM-NOT-012-03
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: >-
  Suite-owned records in the prepared integration workspaces; seeded workspace
  identities remain shared fixtures.
assertion_bindings:
  - scenario: ATS-PFM-NOT-006-08
    suite: TST-PFM-NOT-074
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#cancels,
        not sends, a delivery whose notification was superseded after it was
        queued
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#expires,
        not sends, a delivery whose request has passed its expiry
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#is
        not sent after a cancel took the delivery out of the queue
  - scenario: ATS-PFM-NOT-007-04
    suite: TST-PFM-NOT-074
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#does
        nothing when another consumer already holds the delivery
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#does
        nothing for an item whose delivery is already final, however often it is
        redelivered
  - scenario: ATS-PFM-NOT-007-05
    suite: TST-PFM-NOT-074
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#puts
        a delivery back in the queue after a retryable failure and gives the
        item back after the backoff
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#waits
        longer after each receive, and sends the retry once the provider
        recovers
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#fails
        the delivery attempts_exhausted on the last receive and gives the item
        back at once to reach the dead-letter queue
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#fails
        a permanent refusal at once with the adapter’s code and acknowledges the
        item
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#treats
        an adapter that throws as a retryable failure rather than losing the
        delivery
  - scenario: ATS-PFM-NOT-012-03
    suite: TST-PFM-NOT-074
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#queues
        a delivery that ran out of receives again, with its work row, and
        nothing else
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#refuses
        a delivery the provider refused permanently, leaving it as it was
      - >-
        services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#refuses
        a delivery that is not there
evidence:
  - >-
    services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js
  - The file and referenced assertion titles exist at the pinned commit.
dependency_evidence:
  - >-
    Real: PostgreSQL with row-level security on, the real orchestrator,
    dispatcher, consumer and persistence services. Doubled: the
  - >-
    seam the Slack, Teams and SMS adapters fill in later milestones). Never
    doubled: the database, the lifecycle or the consumer.
---

# deliver delivery

## Verification Boundary

This suite exercises the local services and prepared PostgreSQL database. API lifecycle cases use signed test contexts through the real route handler; they do not invoke the deployed gateway.

## What This Suite Proves

Its cases exercise recheck queued work before sending; skip final work on redelivery; apply transient backoff and permanent failure; retry only exhausted notification deliveries.

The registered scenario bindings identify the assertions this executable file contributes. They retain individual test references so that a composite scenario does not become a claim of complete execution by one file.

## What It Does Not Prove

Local outcomes do not prove deployed queues, external provider acceptance, production credentials or complete browser behavior. No fresh execution or conformance result is claimed.

## Real Dependencies and Test Doubles

The notification fixtures use real PostgreSQL and module logic. Queue publication, visibility changes, nudges and installed channel adapters are recorded at their seams when the suite needs them. Signed API contexts replace the authorizer key in API suites.

## Must Not Be Doubled

Database constraints, workspace policy, state guards and the service operation under test must remain real. Recording a provider or queue call must not replace the submission, claim or outcome logic being checked.