---
id: TST-PFM-DJE-118
title: Contact delete
kind: integration
product_area: platform
module: data-job-engine
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-crm
files:
  - modules/data-jobs/tests/integration/services/jobs/contact-delete.integration.spec.js
implements:
  - ATS-PFM-DJE-007-01
  - ATS-PFM-DJE-007-02
  - ATS-PFM-DJE-007-03
  - ATS-PFM-DJE-007-05
  - ATS-PFM-DJE-007-06
  - ATS-PFM-DJE-007-07
  - ATS-PFM-DJE-007-08
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 fixture records, job identifiers and workspace contexts; teardown removes the fixture
  data.
evidence:
  - >-
    services-crm:modules/data-jobs/tests/integration/services/jobs/contact-delete.integration.spec.js
assertion_inventory:
  - 'a bulk contact delete: the validation in front of it'
  - 'refuses a delete submitted to be applied, because a delete is validated first'
  - 'refuses a record that carries values, naming it, because there is nothing for a delete to write'
  - deletes nothing while it is validating
  - counts the two contacts it would delete and the one it is blocked on
  - 'says what blocks the one it cannot delete, by code'
  - 'counts the rows each delete would take with it, per collection, as the contacts hold them'
  - 'leaves the job waiting to be applied, with the text a person has to type to apply it'
  - 'refuses the locked contact as blocked, and tells the submitter which rule it was'
  - 'a bulk contact delete: the lock a blocked contact is refused for'
  - 'says of the contact locked itself that the contact is locked, naming no element'
  - 'names the locked phone number and its collection, as the single delete of that contact does'
  - 'a bulk contact delete: the two approvals its apply carries'
  - validated the delete of both contacts (premise)
  - refuses an apply that echoes no impact digest
  - refuses an apply whose digest is not the one the validation answered
  - refuses an apply that carries the digest but nothing typed
  - refuses an apply whose confirmation names another number of contacts
  - has deleted nothing through all of those refusals
  - 'accepts the apply that carries both, and queues the job to run'
  - 'a bulk contact delete: what the apply removes'
  - held a task against the first contact before the delete (premise)
  - 'keeps the task of a deleted contact, open'
  - clears the contact the task of a deleted contact named
  - deletes the two contacts nothing blocked
  - leaves no row of theirs in any owned table
  - 'removed, per collection, exactly the number of rows the validation had counted'
  - leaves the locked contact exactly where it was
  - counts the two it deleted and the one it was blocked on
  - 'says of each deleted contact that it was deleted, and not that it was updated'
  - 'finishes the job as completed with rejections, which is what a delete with one blocked record is'
  - 'declares no rollback, so a hard delete can never be undone by a job'
  - >-
    a bulk contact delete: a contact the validation was blocked on and that was unlocked before the
    apply
  - was approved as a delete of the three contacts nothing blocked
  - deletes the three contacts the approval named
  - leaves the contact unlocked since the validation where it was
  - leaves the contact still locked where it was
  - 'counts three applied, the number the confirmation named'
  - >-
    refuses the unlocked contact at the apply with the code the validation refused it with, saying
    why
registration_note: Registration describes existing source; the suite is not executed by this documentation job.
---

# Contact delete

## Verification Boundary

The suite checks the production service or shared engine against its database fixture. The structured assertion inventory records the checks present at the pinned revision.

## What This Suite Proves

The existing checks exercise contact delete. The specification bindings identify the narrower outcomes supported by those assertions.

## What It Does Not Prove

Local execution does not establish deployed queue, storage or service behavior. Independent test cases do not establish a complete cross-feature process.

## Real Dependencies and Test Doubles

The owning service exercises production persistence and domain behavior against real Postgres. The fixture supplies caller contexts; queue delivery, storage and external calls are doubled where the file installs a test port.

## Must Not Be Doubled

The database effects, security context and production operation under examination remain real. Their outcomes cannot be replaced with canned success responses.