---
id: TST-COM-ORD-148
title: The table-backed participant registry
kind: integration
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/participants/tests/integration/services/registry/table-registry.integration.spec.js
implements:
  - ATS-COM-ORD-012-06
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 owns its test application declarations and registry namespaces, and removes those rows after the
  run.
evidence:
  - provenance: test
    source: >-
      services-commerce:modules/participants/tests/integration/services/registry/table-registry.integration.spec.js
    test_cases:
      - >-
        answers a product type’s owner as the manifest declared it, with the current schema version and the
        bound client
      - >-
        answers the pricing policy a manifest declared on a type, stored whole and read back (member pricing
        M5): on for the unlimited type, off for the at-commit one, none for the rest
      - >-
        answers the order_kind a manifest declared on a type, read back from the manifest kept whole
        (contracts 0.3.0): the membership type’s, none for the rest
      - >-
        parses a payload through the in-process participant’s schema, refusing an undeclared version and a
        payload outside it
      - >-
        accepts a remote participant’s payload as the object it is when no schema is published, after the
        version check
      - 'refuses an in-process participant nothing in this process answers for, as participant_unavailable'
      - makes a remote participant’s client from the ARN its row declares
      - >-
        answers a participant by id with its product types, nothing for an unknown one, and every active
        participant in id order
      - 'is what the running macroservice answers, one registry per process'
scenario_coverage:
  - scenario: ATS-COM-ORD-012-06
    test_cases:
      - >-
        parses a payload through the in-process participant’s schema, refusing an undeclared version and a
        payload outside it
      - >-
        accepts a remote participant’s payload as the object it is when no schema is published, after the
        version check
    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/participants/tests/integration/services/registry/table-registry.integration.spec.js
  declared_by_test: >-
    PostgreSQL, the registration, the registry, the in-process bindings. Doubled: the remote client's factory
    (a recorder).
---

# The table-backed participant registry

## Verification Boundary

The suite exercises selling-application registration or registry reads against the local integration database.

## What This Suite Proves

The registered cases check the table-backed participant registry 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.