Inject the failure.
Drive the app. Verify recovery.

Copy the end-to-end prompt

Run this end-to-end fault-injection exercise with your coding and browser tools.

1. Visit the public https://www.starbucks.com/ homepage for visual context only. Do not log in, submit forms, order, call payment APIs, or modify the live page's payment behavior. Respect access restrictions. Create a disposable local practice folder and a simplified local replica based on the observed page, with a fictional latte checkout and synthetic customer data. Label it “Local training replica — not Starbucks.” Do not claim it reproduces Starbucks' actual checkout or backend. If public viewing is blocked, use the course's TestBucks source instead and report the substitution. Do not publish the replica.

2. Serve the replica on localhost. Keep all scripts, state, and simulated payment code local. Disable/remove external form actions, analytics, service workers, and payment endpoints. Use a local mock payment service and an inspectable charge ledger. No real credentials, payment methods, or money. Keep the original course files untouched.

3. Implement a normal synthetic purchase with a stable checkout-attempt ID, order record, and mock charge ledger. Run a baseline purchase in the browser and verify exactly one order and charge. Save the clean baseline before injecting the fault.

4. Dynamically inject a one-shot fault into the LOCAL mock payment code: accept and record the simulated charge, then delay or drop its response until the client times out. This models “payment succeeded, response lost,” not a declined payment. Preserve the attempt ID across retries. Show the injected code diff and fault configuration. Keep baseline and fault runs isolated so their records cannot be confused.

5. Use your browser tools to drive the replica: select a latte and click the simulated payment action. Trigger the injected timeout through the normal payment handler. Have that error path show an accessible dialog titled “Error: fault encountered” with a brief explanation that confirmation timed out, plus Retry and Cancel controls. Do not merely draw an error overlay disconnected from the failure. Capture the visible dialog, the timeout log, and the charge-ledger entry. Distinguish diagnostic UI you added from pre-existing app behavior.

6. Click Retry as a user would. Confirm the same attempt ID is reused and the mock payment service returns the existing charge rather than creating another. Verify exactly one charge and one order remain, the cart/order details are correct, and the UI recovers. Also try a repeated Retry action. If duplicates occur, preserve the failure evidence and report it; do not silently fix the code or delete duplicate records to make the test pass.

7. Remove the injected fault and verify a fresh normal purchase in a separate clean test state. Report baseline, fault, retry, and restored results with screenshots, relevant code changes, logs, attempt IDs, and ledger counts. Describe what was actually executed versus blocked or untested. This demonstrates the local simulator's recovery only—not Starbucks production behavior. Do not claim success merely because an error dialog appeared.

Complete the setup, code injection, browser actions, and verification yourself using available tools. If a required tool or permission is unavailable, report the blocker rather than inventing results. Do not install paid services, provision cloud resources, or send external load.

What to look for

The local mock must model idempotency explicitly. These results do not establish how a real payment provider behaves. No AI service or fault injection runs from this lesson page itself.