What if the same request happens twice?
A slow response is not proof that nothing happened.
Getting startedAbout 2 min read
The uncertain moment after a click
A creator asks an app to generate an image. The screen keeps waiting. They press again, or the application retries for them. It looks like a second attempt at the same action, but the server may already be working on the first one.
This is an example to test, rather than a report of a particular credit loss. In a tool such as InkSpire, a repeated request matters because generation may consume credits and produce work the person expects to keep.
Keep one attempt recognisable
Hiding the button while work is running helps with accidental taps, but it does not settle what happens after a timeout or reconnect. A timeout tells the client it has stopped waiting; it does not necessarily tell it whether the server completed the work.
A common technical approach is an idempotency key: a stable identifier for one intended operation. A repeated request with that key can be recognised and given the recorded result rather than starting or charging again. The server must enforce this, including simultaneous requests; a label on the button cannot do it alone.
Try the interrupted sequence
Ask what happens after a double tap, a slow response, a lost connection and a retry after the result was created. Check the recorded operation and any credit change as well as the visible screen. A deliberate new generation should remain distinguishable from a retry.
The exact design depends on the service. The useful question is small: when someone tries again because they do not know what happened, can the tool find out before doing the work twice?