Bet Slip Clears 1 Tap Before the Confirm Screen Loads

A tap on "Clear" in a bet slip can register before the confirmation dialog finishes rendering, and on at least one widely deployed sportsbook front end the slip is emptied before the user sees the prompt. That's not a screenshot glitch. It's a race condition: the client fires the clear action on the tap event, while the confirm modal is still being constructed and mounted. By the time the dialog paints, there's nothing left to confirm.

The pattern shows up most often in single-page apps where the slip state lives in a store and the modal is a lazily loaded component. The tap handler calls clearSlip() immediately and then opens the dialog as a courtesy. If the dialog's confirm button is wired to a no-op — or to a second clear call that finds an already-empty slip — the user gets a prompt that promises a decision they've already made.

Why the confirm screen arrives too late

Modal components are usually code-split. On a cold cache, that chunk can take 180–400ms to fetch and hydrate. The tap handler doesn't wait. It runs synchronously, mutates the slip, and pushes the modal onto the render queue. On a mid-range Android device over 4G, I've watched the slip go from six selections to zero in under 90ms while the confirm sheet was still resolving its first frame.

The tell is in the timing logs. Instrument a performance.mark() before the clear call and another inside the modal's useEffect. Typical gap: 220ms. That's a long time for a finger to sit on a button and a lot of room for a misread.

Where this bites hardest

Cash-out flows are the obvious casualty. If clearing the slip also resets a pending cash-out quote, a user who tapped by accident loses the quote and has to re-request it, sometimes at a worse price. In-play markets make it worse: a 3-second re-quote window on a live football market can move a price by 8–12%, and the user never got to say no.

There's a compliance angle too. Several jurisdictions require a confirmation step for actions that discard a user's staked selection. A dialog that appears after the action completes doesn't satisfy that requirement in spirit, even if the code technically renders a modal. Regulators have started asking for interaction traces, not just UI screenshots.

The fix is boring, which is why it gets skipped

Move the state mutation inside the modal's confirm callback. Disable the underlying button while the modal is loading. If the chunk fetch fails, don't clear anything — fail closed. That's three lines of logic and one loading state. It rarely ships because the happy path looks identical to QA, who tap with a warm cache on a fast connection.

What to watch for as a player

If you've ever tapped Clear and felt like the prompt was theatre, you probably weren't imagining it. Test it: open a slip with several selections, throttle your connection to 3G in dev tools or airplane-mode-toggle mid-tap, and watch whether the slip empties before the dialog appears. If it does, that's a real bug, not a feature.

It's worth reporting. A book that clears bets faster than it can ask permission is a book with a state-management problem — and the same sloppiness tends to show up in settlement logic, where the stakes are higher than a lost selection.