---
id: TST-COM-FUL-026
title: Adjustment worker
kind: integration
product_area: commerce
module: fulfillment
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-commerce
files:
  - modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js
implements:
  - ATS-COM-FUL-007-01
  - ATS-COM-FUL-007-02
  - ATS-COM-FUL-007-03
  - ATS-COM-FUL-007-04
  - ATS-COM-FUL-009-03
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 3
isolation: >-
  Run-created workspace identifiers and fixture records in the prepared test database; concurrency
  cases own their extra connections.
evidence:
  - repository: services-commerce
    path: >-
      modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js
    test_titles:
      - >-
        plans the five steps of 04 §6 in order with their keys: the memo, the fee, the credit from
        the freed money, its application, the refund of the remainder
      - >-
        plans a credit of the remainder for the credit action, the memo alone for a line never paid,
        and no remainder for none
      - creates the adjustment once (the second request answers the first) with its steps pending
      - >-
        sends every command under its key in order, records Accounting’s reference per step and
        completes the adjustment
      - runs nothing on a settled adjustment
      - >-
        stops at the refund: the four steps before it succeeded, the refund failed, the adjustment
        failed with adjustment_failed raised
      - >-
        resumes from the failed step alone on the retry: only the refund is sent again, and
        completes
      - raised the exception about the adjustment while it was failed
      - 'leaves the step submitted when the command throws, and the resume re-sends the same key'
      - >-
        leaves a retryable refusal pending for the next run, with the attempt counted and no
        exception
      - >-
        is held pending at the processor, never failed, however many times it is asked again, with
        no exception
      - completes with the refund’s reference when the refund has settled
      - 'fails for Finance, with its exception, when the refund then fails at the processor'
      - >-
        answers the working adjustments requested fifteen minutes ago across tenants, oldest first,
        and refuses to run inside a transaction
    scenario_anchors:
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#creates
        the adjustment once (the second request answers the first) with its steps pending
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#plans
        the five steps of 04 §6 in order with their keys: the memo, the fee, the credit from the
        freed money, its application, the refund of the remainder
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#leaves
        the step submitted when the command throws, and the resume re-sends the same key
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#leaves
        a retryable refusal pending for the next run, with the attempt counted and no exception
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#stops
        at the refund: the four steps before it succeeded, the refund failed, the adjustment failed
        with adjustment_failed raised
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#is
        held pending at the processor, never failed, however many times it is asked again, with no
        exception
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#completes
        with the refund’s reference when the refund has settled
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#fails
        for Finance, with its exception, when the refund then fails at the processor
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#answers
        the working adjustments requested fifteen minutes ago across tenants, oldest first, and
        refuses to run inside a transaction
---

# Adjustment worker

## Verification Boundary

This suite checks adjustment worker against the prepared PostgreSQL database. Its entry points are the persistence and service functions used by the tests.

## What This Suite Proves

The bound scenarios identify the assertions this suite contributes. Source anchors retain the exact test cases; where a capability scenario has several contributing suites, a single binding does not imply that every branch runs here.

## What It Does Not Prove

Direct service and persistence calls do not establish the full HTTP permission contract, deployed scheduling or browser behavior. No execution result is claimed by this register.

## Real Dependencies and Test Doubles

The database and imported Commerce persistence services are real. Fixtures create the records owned by this run. Accounting command responses use the suite’s fixture port. Time-sensitive cases use a controlled clock where the source fixture supplies one.

## Must Not Be Doubled

Keep the database constraints, row visibility and persistence writes real when claiming this integration coverage. A canned repository response cannot replace the boundary being checked.