Prove a lost payment response cannot create two orders
The payment double accepts a charge but drops the response. The customer clicks Try again. The regression must verify one charge and one order, not just a success banner.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Idempotency testing · Fault injection · Distributed systems
Estimated field mix
- Quality engineering60%
- Distributed systems40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A small commerce team has happy-path browser tests but still ships rounding and retry defects. Model a fictional shop using synthetic products, a local payment double, and explicit cart rules before adding regression coverage.
Setup prerequisites
- Create or provide a local checkout fixture application.
- Model products, tax rules, inventory, and a payment-provider double using synthetic data.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- The double can accept a payment and deterministically lose the first response.
- Retry preserves the intended checkout idempotency identity.
- Assertions inspect order count, charge count, amount, and final customer-visible status.
Implementation constraints
- Record provider requests in the local double; do not connect a real payment account.
Verification to include
- Run a lost-response-then-retry case and assert one durable charge and one order.
- Use a fixture defect that rotates the idempotency key on retry and confirm the regression detects the duplicate.
Deliverables
- Lost-response payment scenario and durable-state assertions
Rollout and recovery
Add to checkout gates with bounded local timeouts; keep provider behavior versioned with the test.
Value of the work
For the engineer: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures.
For the team: Review whether a test suite catches business regressions and explains failures without creating noisy release gates.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.