---
id: TST-COM-FUL-045
title: Obligation 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/register/obligation-worker.integration.spec.js
implements:
  - ATS-COM-FUL-004-02
  - ATS-COM-FUL-004-04
  - ATS-COM-FUL-004-05
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/register/obligation-worker.integration.spec.js
    test_titles:
      - acknowledges the item and completes the obligation with the participant’s record
      - 'logs the attempt in process with its latency, and the history line by the participant'
      - >-
        acknowledges a redelivery of the same item as stale, writing one stale attempt and nothing
        else (A17)
      - >-
        leaves the obligation in progress with a deadline, then the callback completes it; a repeat
        of the callback answers the same
      - >-
        fails the obligation with the participant’s code, raises obligation_failed, and acknowledges
        the item
      - >-
        reports the item failed on receives one to four, leaving the obligation in flight with the
        attempts counted
      - >-
        fails it attempts_exhausted on the fifth receive, raises the exception, and still reports
        the item failed so the queue dead-letters it
      - 'logs an unavailable attempt and reports the item failed, leaving the obligation authorized'
      - 'junk, and an item whose authorization is not the obligation’s current one'
    scenario_anchors:
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#acknowledges
        a redelivery of the same item as stale, writing one stale attempt and nothing else (A17)
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#junk,
        and an item whose authorization is not the obligation’s current one
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#fails
        the obligation with the participant’s code, raises obligation_failed, and acknowledges the
        item
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#reports
        the item failed on receives one to four, leaving the obligation in flight with the attempts
        counted
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#fails
        it attempts_exhausted on the fifth receive, raises the exception, and still reports the item
        failed so the queue dead-letters it
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#logs
        an unavailable attempt and reports the item failed, leaving the obligation authorized
      - >-
        services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#leaves
        the obligation in progress with a deadline, then the callback completes it; a repeat of the
        callback answers the same
---

# Obligation worker

## Verification Boundary

This suite checks obligation 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. Financial facts are supplied by a local fixture provider. Queue publication uses the suite’s recording or scripted publisher. 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.