Wallet failure drills
Wallet failure drills
Before production, prove operator flow handles non-happy wallet outcomes safely.
Run only against dedicated staging users and non-production wallet infrastructure. The built-in user-scoped simulator, the separate HTTP Operator Simulator, and a real operator REST v1 adapter are different paths; success in one does not establish the others.
Debit failure drill
Expected result:
- debit operation ->
failed - order ->
failed - no AMM trade created
- webhook failure event emitted
Use a controlled adapter rejection with a valid failed receipt or a definite HTTP error without an applied wallet effect. The current dashboard has no fail_debit selector.
Debit unknown drill
Expected result:
- debit operation ->
unknown - order ->
manual_review - no AMM trade executed until resolution
- failure or manual-review webhook evidence present
Use a controlled timeout-after-apply or ambiguous response. The separate HTTP simulator supports debit_applied_then_timeout for a confirmed dedicated test user; the dashboard does not expose an unknown_debit selector.
Credit failure drill
Expected result:
- payout-side balance operation ->
failed - redemption or sell item ->
manual_review - operator must inspect before any replay or retry decision
Use a controlled adapter response with status: "failed". The current dashboard has no fail_credit selector. An unpaid sell/redemption remains a financial obligation; a failed operation is not authorization to discard it.
Credit unknown drill
Expected result:
- payout-side balance operation ->
unknown - redemption or sell item ->
manual_review - operator wallet evidence and human review required
The separate HTTP simulator supports credit_applied_then_timeout for a dedicated test user. Do not assume the dashboard exposes unknown_credit, or that a timeout means the operator wallet did not credit.
Polyflight drills
Run the same transport failures against each Polyflight effect, using its stable key:
| Scenario | Required observation |
|---|---|
| Definite purchase rejection | No ticket, no fee/position income, no money assumed moved. |
| Purchase debit applied then timeout | No automatic debit replay; manual evidence determines admission or exact compensation. |
| Win/refund credit applied then timeout | Result/cancellation remains final, obligation stays unresolved until evidence, no duplicate credit. |
| Same key and same payload | Original effective result returned with no second mutation. |
| Same key and different payload | Conflict, no mutation. |
| Cancel admitted ticket | Full original stake credited with the refund key; no winning obligation. |
| Late admitted attempt after confirmed debit | Gate rejects the ticket and exact debit reversal is scheduled. |
| Losing ticket | Exactly zero /credit acknowledges result: "lost" once, does not change balance or owe money, and its duplicate returns the same effective result. Ambiguity retains delivery reconciliation. |
| Conflicting response identity | Wrong user, key, currency or amount echo produces unknown/manual-review handling, never success for the intended operation. |
Test both OpenPoly's user-scoped simulator and a separate real REST v1 test adapter. Simulator results are not external-wallet certification.
For the separate Operator Simulator's per-user wallet drill, the current choices are off, debit_applied_then_timeout, credit_applied_then_timeout, and definite_rejection; non-off modes require dedicated-test-user confirmation. The adapter full-contract API additionally accepts normal, duplicate_same, and duplicate_conflict scenarios. These are not ordinary launch metadata controls. See scenario inputs and expected results.
After an unknown result, preserve the original operation and request fingerprint. Reconcile authenticated operator-ledger evidence before any authorized resolution. Do not generate a new financial key, reset the wallet to conceal the discrepancy, replay a webhook to retry money, or repeat the full-contract drill as recovery.
What to capture for each drill
idempotency_key- Opinion order/redemption ID or Polyflight purchase/ticket/flight IDs
- balance operation ID and payment-obligation status when applicable
- final status
- failure reason
- webhook event ID if emitted
- statement/liability/export result when the scenario creates or clears a Polyflight obligation
Pass criteria
- no duplicate debit or credit side effect
unknownalways escalates to manual review- operator team can explain exact next step for each failure state