Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-004Carry authorized work to its delivering application: Acceptance Test Set

Markdown

ATS-COM-FUL-004

Carry authorized work to its delivering application: Acceptance Test Set

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-004

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision1

Read atservices-commerce c8b66a98

Test Scenarios

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

01 Dispatch removes only queue-accepted entriesapitest
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 resultapinegativetest
Proves
BR-CAP-COM-FUL-004-03
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 excessapitest
Proves
BR-CAP-COM-FUL-004-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 exhaustionapinegativetest
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 authorityapitest
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 redispatchapitest
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 statesapinegativetest
Proves
BR-CAP-COM-FUL-004-10 BR-CAP-COM-FUL-004-11
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)

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