---
id: TST-COM-ORD-096
title: Tender-window sweep
kind: integration
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js
implements:
  - ATS-COM-ORD-008-08
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 2
isolation: The suite creates its own test workspace records and removes them using the fixture cleanup.
evidence:
  - provenance: test
    source: >-
      services-commerce:modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js
    test_cases:
      - >-
        answers what it did: the three placed orders past their window of both tenants found and voided, none
        skipped
      - >-
        voided each in its own tenant: the reason tender_window_expired, the reservation released, the
        obligation cancelled, the history told by the system
      - >-
        asked the billing port to delete the pro forma invoice of the billed order, and wrote its deferred
        answer on the history
      - 'left the live, the terms, the accepted and the already voided orders as they were'
      - finds nothing on a second run
      - 'takes at most the limit, oldest window first, and leaves the rest to the next run'
scenario_coverage:
  - scenario: ATS-COM-ORD-008-08
    test_cases:
      - >-
        voided each in its own tenant: the reason tender_window_expired, the reservation released, the
        obligation cancelled, the history told by the system
      - 'left the live, the terms, the accepted and the already voided orders as they were'
      - 'takes at most the limit, oldest window first, and leaves the rest to the next run'
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
dependency_evidence:
  provenance: test
  source: >-
    services-commerce:modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js
  declared_by_test: >-
    PostgreSQL (the sweep policy of migration `20261017215015`), the persistence services, the execution
    contexts under `rhythm_commerce_app`, the void. Doubled: the billing port (the fixture, which is what the
    running macroservice carries until P3-WP01); the participant registry answers no participant for the
    fixture's `merchandise`, so no SQL function is called and the ledger alone is released.
---

# Tender-window sweep

## Verification Boundary

The suite exercises persistence or workflow operations against the local integration database.

## What This Suite Proves

The registered cases check tender-window sweep with their fixture records and assertions. Scenario bindings name only the examples those cases exercise.

## What It Does Not Prove

A registered file supplies no run result or verified conformance by itself. Local fixtures do not establish deployed cross-service behavior or complete browser journeys.

## Real Dependencies and Test Doubles

PostgreSQL and the exercised Commerce persistence or workflow code are real. Remote service records, clocks and transports follow the suite’s fixtures.

## Must Not Be Doubled

The database constraints, role restrictions, locks and transactions exercised by this suite must use PostgreSQL.