Chapter 31 — Cancellation, Returns, Reservations and Failure Handling¶

Completed order stages determine subsequent services. Cancellation and return are new activities; rollback and inverse execution restore the original failed activity. Both can reverse changes but have different meanings.

Follow Established Facts¶

These are alternative branches, not consecutive steps on one order:

Return request needs buyer, original order and request. Approval adds funds and stock. Policies requiring physical receipt first need that fact and eligibility; demo rules are not universal.

Use confirmed amounts and quantities, not old wallet/stock snapshots that erase later business.

Business Refund Versus Automatic Inverse¶

Canceling a successful payment is new refund business with eligibility, contract and receipt. Undoing a payment that failed during execution restores its original effects; quantum inverses need no separate business service.

Ordinary restoration protects later versions under Part IV, Chapter 21. The current implementation still requires corresponding compensation capability; simple save logic is not proof all deployments already provide automatic conditional inverse updates.

If quantum funds settle but cross-resource order save fails, APP recovers committed phases. Full confirmed recovery permits declaring reversal; partial failure remains pending. SPP does not take over remote result queries and database retries.

Reservation Intentionally Retains Acceptance¶

The reservation scenario first saves acceptance and number, then reserves and confirms in a second transaction. Competition may cause the second to fail while acceptance survives.

With ten available and eleven requested, quantum bounds reject reservation. After confirmed rollback or inverse execution, the scenario records rejection while keeping the number for queries.

The second boundary is:

transaction {
    reserveRequestedInventory bounds {
        StockLine[].available: [0, null];
        StockLine[].reserved: [0, null];
    };
    confirmPetReservation; updatePetReservationAgreement;
} fail {
    if (ResultInfo.failure.recoveryStatus == "ROLLED_BACK" ||
        ResultInfo.failure.recoveryStatus == "REVERSED") {
        findStockLine; identify(StockLine[]);
        rejectPetReservation;
        transaction { updatePetReservationAgreement; }
    }
}

The fresh stock query supports reason selection: insufficient current stock versus another incomplete reservation. Model and calculation define it. Business does not catch database exceptions; it handles accepted applications after recovery confirmation.

Three Different Failure Paths¶

Definite meaningful technical failures can reach business handling. Timeout is not automatically insufficient stock and must not make fail reserve again. The guard prevents that error.

If the rejection save fails, do not pretend it persisted. Preserve evidence and continue confirmation. ResultInfo describes this execution; stored status and reason describe the application.

Verify Completion with Faults¶

Check insufficient stock, ordinary-save failure after quantum changes, and unknown results. The first two require stock, application state and reason checks; unknown requires recovery records and no repeated reservation.

See failure evidence. LOCAL tests alone do not prove every real cross-domain recovery. Check resources and evidence together next.

Part Contents · Full Book Contents · Previous Chapter · Next Chapter