---
id: TST-PFM-NOT-036
title: process communication request
kind: integration
product_area: platform
module: notifications
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js
implements:
  - ATS-PFM-NOT-017-05
  - ATS-PFM-NOT-017-06
  - ATS-PFM-NOT-017-07
  - ATS-PFM-NOT-018-02
  - ATS-PFM-NOT-018-03
  - ATS-PFM-NOT-018-04
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-017-05
    suite: TST-PFM-NOT-036
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#stores
        why nothing was sent where staff can read it
  - scenario: ATS-PFM-NOT-017-06
    suite: TST-PFM-NOT-036
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#writes
        the message under the id derived from the request, never a generated one
  - scenario: ATS-PFM-NOT-017-07
    suite: TST-PFM-NOT-036
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#stores
        the request invalid, naming the object rather than crashing
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#sends
        nothing for it
  - scenario: ATS-PFM-NOT-018-02
    suite: TST-PFM-NOT-036
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#sends
        nothing a second time
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#writes
        no second message and leaves the one there is as it was
  - scenario: ATS-PFM-NOT-018-03
    suite: TST-PFM-NOT-036
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#stops
        the rest of the request for this receive rather than pressing an unwell
        provider
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#gives
        the item back with the backoff of this receive, which SQS times and
        Postgres does not
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#sends
        all three on the next receive, each exactly once
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#defers
        nothing: what the provider refused is failed as attempts_exhausted
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#still
        sends the e-mails the failure did not reach, so one bad recipient does
        not hold the rest
  - scenario: ATS-PFM-NOT-018-04
    suite: TST-PFM-NOT-036
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#offers
        the exhausted e-mail to the provider again
      - >-
        services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js#never
        offers one the provider already took: the request is settled, not
        re-sent
evidence:
  - >-
    services-platform:modules/communications/tests/integration/services/dispatch/process-communication-request.integration.spec.js
  - The file and referenced assertion titles exist at the pinned commit.
dependency_evidence:
  - >-
    Real: PostgreSQL (the prepared integration database, row-level security on),
    submission, the dispatcher, acceptance, the
  - >-
    send function and the consumer. Doubled: SES at the transport (with scripted
    failures), the object store and the send
  - >-
    queue (recorded). Never doubled: the database, its constraints, or anything
    the consumer calls.
---

# process communication request

## 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 retain all non-sending outcomes and reasons; pin published content and derive message identities; reject missing and mismatched stored objects; skip final and temporarily ambiguous submissions; back off throttled sends and expose exhaustion; redrive only exhausted sends.

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 communication fixtures use real PostgreSQL and module logic. Shared support records queue and transport calls and stores objects in memory; sender provisioning substitutes a provider identity store. 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.