ENGINEERING NOTE 04 / 50 · SMS
Resolve an SMS cancellation that races with delivery
A cancellation request is an intent, not proof that an upstream order was cancelled. Reconcile the authoritative outcome before committing a refund.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Record intent first
Persist cancel_requested with an operation identifier before calling the upstream system. The browser can show that processing is underway. If the connection drops, another worker can resume the same operation rather than creating a new one.
Read after uncertainty
When the cancellation response is ambiguous, query the same order using its original routing identity. Do not switch to another provider for an existing order. A message that arrived before cancellation confirmation may change eligibility under the applicable order terms.
Serialize the financial outcome
Commit the refund with a unique key tied to the original debit. A repeated callback must find the existing result. If contradictory terminal events remain, use a review state instead of guessing from arrival order. Never display refund complete before the credit entry exists.
Illustrative implementation
cancel intent -> upstream request
ambiguous response -> query original order
confirmed eligible -> unique refund(original_debit_id)
contradiction -> review_requiredAcceptance check
Inject delivery before, during and after cancellation. Confirm that each scenario produces at most one refund and an explainable timeline.