---
id: TST-PFM-SEC-263
title: Reset workspace database and service checks
kind: integration
product_area: platform
module: security
revision: 2
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js
implements:
  - ATS-PFM-SEC-003-12
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 3
isolation: Use the prepared test database and suite-owned fixture rows; retain shared seed records.
assertion_evidence:
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#the
      tenant reset: a loading tenant emptied of its import, measured rather than reported
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#what
      the fixture wrote (the premise)
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#seeded
      rows in every table a reset empties, so a zero afterwards is a removal and not an empty table
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#seeded
      rows in the tables a reset is kept for, so an unchanged count afterwards means something was
      there to keep
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#opening
      the load
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#puts
      the tenant into its loading state
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#leaves
      the status as the implementation mode it has to be in
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#records
      who opened it, when, and why
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#asking
      for it
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#answers
      the tenant and the job that empties it
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#records
      the reason on the job, where the request no longer answers it
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#the
      job
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#succeeds
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#takes
      more task invocations than the plan has participants, each participant needing more than one
      batch
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#asked
      the other macroservice for one batch per invocation, a batch at a time, until it held nothing
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#ran
      the whole plan: the cursor stands past its last participant
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#reports
      one progress event per participant, naming what that participant removed
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#names
      the other macroservice’s removed records by resource in its progress event
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#ends
      at full progress
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#is
      what the reset read answers for the tenant
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#what
      the reset removed
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#empties
      every table of every participant it empties, but the configuration a participant’s own reset
      keeps
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      the custom objects and the association types a participant’s own reset keeps
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#reports
      one result per participant it empties, and names no participant it keeps
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#counts
      what it removed under the resources the participants count by
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#names
      the tenant and the reason it was given
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#asked
      the other macroservice to reset, not to purge
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#let
      the other macroservice re-apply its seeds, which is what a reset has and a purge has not
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#what
      the reset kept
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      the tenant row itself, which is the whole point of a reset
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      every table of every participant it does not empty, row for row
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      the record of earlier resets, and adds its own
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#leaves
      the tenant loading, so the corrected package can be loaded at once
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#another
      tenant of the same customer
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      every row it had, in every table
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#activating
      the tenant afterwards
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#returns
      it to active, so its own people reach it again
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#leaves
      the status alone: going live is the separate decision
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      the record of the load, which is the evidence of what was done to the tenant
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#the
      tenant reset: the state and the confirmation it refuses
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#entering
      the loading state
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      a live tenant by name: an initial import loads only an implementation tenant
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#leaves
      the live tenant active after that refusal
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#changes
      nothing when the tenant is already loading, so a repeated step is not an error
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#resetting
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      a tenant that is not loading, naming that half of the rule
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      a live tenant, naming the other half
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      a confirmation that is not the tenant’s id, and does not say what to type
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      a missing confirmation
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#leaves
      the tenant loading after a refused confirmation, having removed nothing
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#records
      no reset job for any tenant it refused
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#activating
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      a tenant nobody was loading
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#the
      tenant reset: a macroservice that does not declare it
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      the reset, naming the service and the contract it has to implement
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#removes
      nothing at all: a half-reset tenant is the outcome worth refusing for
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#asked
      the service for nothing but its manifests
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#records
      no reset job: the tenant’s latest is still the one its seed wrote
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#the
      tenant reset: a second request while one is running
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      the second request as a conflict, naming the job that is running
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#starts
      no second reset: the tenant’s latest reset is still the first
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#refuses
      before it asks any participant anything
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#the
      tenant reset: a reset interrupted half-way, and the request that finishes it
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#interrupted
      the first reset part of the way through its plan
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#left
      the tenant partly reset when it was interrupted, which is the state the second request has to
      finish
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#accepts
      a second reset once the first has settled, and the second succeeds
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#empties
      every table of every participant a reset empties, but the configuration a participant’s own
      reset keeps
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      the custom objects and the association types a participant’s own reset keeps, across both
      resets
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      every table of every participant it does not empty, row for row, across both resets
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#keeps
      the record of both resets, the interrupted one and the one that finished
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#finds
      nothing left to remove of the participants the first reset had already emptied
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js#leaves
      the tenant loading
dependency_evidence: >-
  The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here.
  The suite controls workflow execution, remote service participants, the clock at the declared
  seams; those collaborators remain outside its live proof.
evidence:
  - >-
    services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js
  - >-
    Static review at the recorded source revision; executable results remain not-run and conformance
    remains not-verified.
binding_note: >-
  Each binding names the scenario to which this file contributes assertions. A binding is not a
  recorded pass and does not extend the file’s dependency boundary.
examiner: codex
examined_at: '2026-10-23'
final_text: OpenAI
dependency_review:
  provenance: test
  source: >-
    services-platform:modules/tenants/tests/integration/services/reset/reset-tenant.integration.spec.js
  explicit_no_doubles: false
  identified_double_boundaries:
    - workflow execution
    - remote service participants
    - the clock
---
# Reset workspace database and service checks

## Verification Boundary

The file exercises database or service behavior through the local integration harness. The assertion references identify the source checks for reset workspace.

## What This Suite Proves

The source assertions support the observations named in the bound scenarios. A scenario spanning multiple files must retain the other files’ contributions.

## What It Does Not Prove

This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence.

## Real Dependencies and Test Doubles

The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The suite controls workflow execution, remote service participants, the clock at the declared seams; those collaborators remain outside its live proof.

## Must Not Be Doubled

Keep the queried database, applicable constraints and transaction boundaries real. Provider substitutes cannot establish delivery, cloud execution or cross-service recovery.