Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-004Carry authorized work to its delivering application: Capability Test Specification

Markdown

ATS-COM-FUL-004

Carry authorized work to its delivering application: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-004

Design

Executed by
TST-COM-FUL-018, TST-COM-FUL-021, TST-COM-FUL-022, TST-COM-FUL-023, TST-COM-FUL-024, TST-COM-FUL-025, TST-COM-FUL-040, TST-COM-FUL-041, TST-COM-FUL-044, TST-COM-FUL-045, TST-COM-FUL-047, TST-COM-FUL-055, TST-COM-FUL-078

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Carry authorized work to its delivering application: Capability Test Specification ​

Coverage ​

The category map distinguishes available cases from missing proof. A covered category has a scenario; the lifecycle and permission audits retain gaps in exhaustive coverage. Proposed cases describe the intended verification and carry no execution result.

RuleScenarios
BR-CAP-COM-FUL-004-01ATS-COM-FUL-004-01
BR-CAP-COM-FUL-004-02ATS-COM-FUL-004-01
BR-CAP-COM-FUL-004-03ATS-COM-FUL-004-02, ATS-COM-FUL-004-09
BR-CAP-COM-FUL-004-04ATS-COM-FUL-004-03, ATS-COM-FUL-004-12
BR-CAP-COM-FUL-004-05ATS-COM-FUL-004-04
BR-CAP-COM-FUL-004-06ATS-COM-FUL-004-04
BR-CAP-COM-FUL-004-07ATS-COM-FUL-004-05, ATS-COM-FUL-004-08, ATS-COM-FUL-004-10, ATS-COM-FUL-004-11
BR-CAP-COM-FUL-004-08ATS-COM-FUL-004-05, ATS-COM-FUL-004-08, ATS-COM-FUL-004-10, ATS-COM-FUL-004-11
BR-CAP-COM-FUL-004-09ATS-COM-FUL-004-06
BR-CAP-COM-FUL-004-10ATS-COM-FUL-004-07, ATS-COM-FUL-004-13
BR-CAP-COM-FUL-004-11ATS-COM-FUL-004-07, ATS-COM-FUL-004-13

The interaction cases exercise understand and intervene in an order's delivery; handle financial reversals after delivery; record goods leaving with a carrier or collector. They vary the upstream record or outcome and inspect the resulting work across the capability boundary. Workflow crossings also include stock, financial or application records when the flow depends on them. Existing test bindings retain their source anchors so a reviewer can distinguish supporting assertions from a complete workflow run.

Coverage

  • Rule gap: FND-COM-FUL-059
  • Transition covered
  • Validation gap: FND-COM-FUL-059
  • Permission covered
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency gap: FND-COM-FUL-059
  • Invariant covered
  • Interaction covered

Test Scenarios

13 scenarios proving CAP-COM-FUL-004; 12 bound to an existing test.

01 Dispatch removes only queue-accepted entriesfailureapitest
Proves
BR-CAP-COM-FUL-004-01 BR-CAP-COM-FUL-004-02
Preconditions
Three authorizations span two workspaces and one publication is rejected.
Steps
Dispatch twice and separately exercise a thrown publish.
Expected
Accepted entries disappear, rejected work remains for the next run and a thrown publish preserves its entries.
Data
Fixtures for dispatch removes only queue-accepted entries.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/register/obligation-dispatcher.integration.spec.js#claims the three rows of both tenants, publishes a pointer for each, and reports the refused one
services-commerce:modules/fulfillment/tests/unit/register/obligation-queue.spec.js#is a pointer: the version, the tenant, the obligation and the authorization, and nothing of the row’s content
Source
services-commerce:modules/fulfillment/tests/integration/services/register/obligation-dispatcher.integration.spec.js#claims the three rows of both tenants, publishes a pointer for each, and reports the refused one
02 Old delivery pointers retain the completed resultedgeapinegativetest
Proves
BR-CAP-COM-FUL-004-03 INV-DOM-COM-FUL-001-06
Preconditions
An obligation has completed under its current authorization.
Steps
Replay that pointer and a pointer using an obsolete authorization.
Expected
Each is acknowledged with a stale attempt while the delivery result remains unchanged.
Data
Fixtures for old delivery pointers retain the completed result.
Bound to
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/persistence/obligation-register.integration.spec.js#answers a repeat as not in flight with a stale attempt, changing nothing (A17)
Source
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)
03 Completion tracks partial quantities and rejects excessboundaryapitest
Proves
BR-CAP-COM-FUL-004-04 INV-DOM-COM-FUL-001-04
Preconditions
One obligation owes three units.
Steps
Complete one unit, complete the remainder and attempt excess completion.
Expected
Progress advances from one to three units and excess completion is rejected.
Data
Fixtures for completion tracks partial quantities and rejects excess.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#records partial completion as in progress with the units, then completes when the rest arrive
services-commerce:modules/fulfillment/tests/integration/db/obligations.table.integration.spec.js#refuses more completed than owed, and an operation or state outside the contract, by their checks
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#records partial completion as in progress with the units, then completes when the rest arrive
04 Delivery failures distinguish retry from exhaustionfailureapinegativetest
Proves
BR-CAP-COM-FUL-004-05 BR-CAP-COM-FUL-004-06
Preconditions
Applications permanently refuse, temporarily refuse or cannot be reached.
Steps
Invoke each path and deliver the retrying work five times.
Expected
Permanent failure produces an exception; retrying work remains in flight until final exhaustion.
Data
Fixtures for delivery failures distinguish retry from exhaustion.
Bound to
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
Source
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
05 Callbacks finish long-running delivery under current authoritypermissionapitest
Proves
BR-CAP-COM-FUL-004-07 BR-CAP-COM-FUL-004-08
Preconditions
The application has returned an in-progress answer.
Steps
Complete by callback, repeat it and try obsolete authorization and reader credentials.
Expected
Completion occurs once, repetition returns its result and invalid callers or authorizations are rejected.
Data
Fixtures for callbacks finish long-running delivery under current authority.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#completes the obligation and answers it as it stands; the repeat answers the same
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#refuses a callback under an authorization that is not the current one, 409 authorization_not_current
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#refuses the callback routes to a console reader (403) and to a portal member, and a body outside the contract 400
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
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#records the participant’s prerequisite once and answers the obligation
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#completes the obligation and answers it as it stands; the repeat answers the same
06 Acknowledgement expiry permits one redispatchtransitionapitest
Proves
BR-CAP-COM-FUL-004-09
Preconditions
Delivery has passed its acknowledgement deadline.
Steps
Sweep after the first expiry and after the extended deadline.
Expected
Work is sent again once, then fails for lost acknowledgement.
Data
Fixtures for acknowledgement expiry permits one redispatch.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#re-dispatches the overdue authorization once, moving its deadline on, and leaves the other
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#fails it ack_lost on the next deadline, with the exception raised and the history line written
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#re-dispatches an in-flight authorization once, extending the deadline, and refuses the second time
Source
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#re-dispatches the overdue authorization once, moving its deadline on, and leaves the other
07 Database guards preserve legal obligation statesinvariantapinegativetest
Proves
BR-CAP-COM-FUL-004-10 BR-CAP-COM-FUL-004-11 INV-DOM-COM-FUL-001-01 INV-DOM-COM-FUL-001-02 INV-DOM-COM-FUL-001-03
Preconditions
The register contains fixtures for each lifecycle state.
Steps
Write invalid transitions and duplicate unit obligations directly.
Expected
The database refuses every invalid transition and duplicate identity.
Data
Fixtures for database guards preserve legal obligation states.
Bound to
services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#refuses pending to authorized, authorized to pending, failed to completed and completed to anything but superseded (RHC02)
services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#allows blocked to cancelled (D-P4-03) and failed to resolved, then nothing out of either
services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#refuses an authorized or in-progress obligation without its authorization (obligations_authorization_state_check)
services-commerce:modules/fulfillment/tests/integration/db/obligations.table.integration.spec.js#refuses moving a completed obligation anywhere but superseded, SQLSTATE RHC02, and lets it be superseded
services-commerce:modules/fulfillment/tests/integration/db/obligations.table.integration.spec.js#refuses a second obligation for the same subject, operation and unit, by obligations_subject_uq
Source
services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#refuses pending to authorized, authorized to pending, failed to completed and completed to anything but superseded (RHC02)
08 Membership delivery opens the dependent merchandise gateinteractionapitest
Proves
BR-CAP-COM-FUL-002-07 BR-CAP-COM-FUL-003-02 BR-CAP-COM-FUL-003-03 BR-CAP-COM-FUL-004-04
Preconditions
A paid cart contains a membership and a member-priced shirt. Both have waiting delivery work.
Steps
Evaluate payment, deliver the membership and then dispatch the shirt.
Expected
The shirt waits before membership completion, records its satisfied prerequisite, then completes delivery.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/same-cart-grants.e2e.spec.js#delivers the membership, meets the T-shirt’s prerequisite with order.prerequisite_met on the history, and opens its gate
Source
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#the participant’s prerequisite is waited for, and a child line follows its parent unless the policy says not,services-commerce:modules/fulfillment/tests/e2e/same-cart-grants.e2e.spec.js#delivers the membership, meets the T-shirt’s prerequisite with order.prerequisite_met on the history, and opens its gate,services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#completes the obligation and answers it as it stands; the repeat answers the same
09 Authorization reaches its application once despite a replayed pointerinteractionapitest
Proves
BR-CAP-COM-FUL-002-09 BR-CAP-COM-FUL-004-03
Preconditions
An accepted paid order has a waiting obligation.
Steps
Evaluate payment and replay its event, dispatch the instruction, complete it and replay its pointer.
Expected
One authorization remains and replay retains the completed result.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#is idempotent on the event id: the batch redelivered answers succeeded, evaluates nothing and opens nothing
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#answers failed with the error for an event whose evaluation threw, and leaves no receipt, so its redelivery evaluates
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#answers succeeded for every event, the unknown tenant and the unsold line among them, and applies the four
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#is idempotent on the event id: the batch redelivered answers succeeded, evaluates nothing and opens nothing,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)
10 Manual completion closes application delivery before a late callbackinteractionapinegativetest
Proves
BR-CAP-COM-FUL-004-07 BR-CAP-COM-FUL-005-07
Preconditions
An application left the authorized obligation in progress. Staff have manual-completion authority.
Steps
Complete with a reason and evidence, then send the application callback using the earlier authorization.
Expected
The recorded manual result remains and the late callback fails.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the manual completion without the evidence (400) and to a reader (403), then completes it with the records and the note
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the participant’s late callback as not in flight, leaving the manual completion
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#completes the obligation and answers it as it stands; the repeat answers the same,services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the manual completion without the evidence (400) and to a reader (403), then completes it with the records and the note
11 Reversal enforcement completes beside the original delivery and remains reviewableinteractionapitest
Proves
BR-CAP-COM-FUL-004-04 BR-CAP-COM-FUL-006-02 BR-CAP-COM-FUL-006-03 BR-CAP-COM-FUL-008-01
Preconditions
A delivered membership uses suspension on reversal and a delivered seat uses staff review.
Steps
Reverse their payments, dispatch the acting instruction, and inspect the review queue.
Expected
The membership is suspended beside its unchanged delivery result; the seat remains a staff review.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/enforcement.e2e.spec.js#suspends the membership in the participant with the enforcement id stored, the original obligation still completed, the enforcement completed
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#completes the obligation and answers it as it stands; the repeat answers the same,services-commerce:modules/fulfillment/tests/integration/services/enforcement/enforcement-handler.integration.spec.js#creates four enforcements: three dispatched (suspend, cancel_line, notify), one for a person (review); the none policy and the pending obligation get nothing,services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#lists the finding the reconciler raised about the unbilled order, filtered by kind, state and order, and never another tenant’s
12 Warehouse departure supplies the physical application outcomeinteractionapitest
Proves
BR-CAP-COM-FUL-004-04 BR-CAP-COM-FUL-014-01 BR-CAP-COM-FUL-018-05
Preconditions
Three picked units have current delivery authorization and a manifested shipment.
Steps
Hand the shipment to its carrier, then inspect allocation units and delivery detail.
Expected
The three units are shipped and their obligations are completed with the allocation references.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#completes every unit’s obligation through the register (the allocation as the record), and emits one deferred cost relief fact per item
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#writes the shipped quantity on the order line, the order’s shipping_summary complete, and the order’s history
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#records partial completion as in progress with the units, then completes when the rest arrive,services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand,services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#counts a held row against held, a committed one against allocated and a released one against nothing, through the trigger
13 Migrated delivery remains distinguishable from new waiting workinteractionapiproposed
Proves
BR-CAP-COM-FUL-020-11 BR-CAP-COM-FUL-002-02 BR-CAP-COM-FUL-004-10
Preconditions
A historical order contains one delivered item and one undelivered item.
Steps
Import the order and inspect its two obligations; evaluate the undelivered line.
Expected
Imported delivery remains completed while the undelivered migrated line remains blocked for staff.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js#writes the order with its 1.0 number, accepted at its placement, billed, and marked migrated,services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#blocks for a person exactly when the reason is a hold, a migrated line, a missing approval or a prerequisite that failed, and never otherwise,services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#refuses pending to authorized, authorized to pending, failed to completed and completed to anything but superseded (RHC02)

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software