Представим обычную ситуацию.Пользователь нажимает «Оплатить». Ответа нет. Он ждёт несколько секунд и нажимает ещё раз. А потом получает две оплаты. На первый взгляд кажется: сам виноват, зачем нажимал дважды? Но всё интереснее.

Сервер мог успешно обработать первый запрос, но ответ не дошёл до клиента из-за проблем с сетью. Пользователь получил timeout и решил, что операция не произошла. Хотя на сервере она уже завершилась.

Получается парадокс: для клиента запрос неуспешный, а для сервера — успешный.

Именно поэтому для некоторых операций используют идемпотентность. Клиент передаёт уникальный Idempotency-Key, а сервер запоминает результат операции. Если тот же запрос приходит повторно с тем же ключом, сервер не выполняет операцию заново.

Но для QA на этом проверка только начинается. Я бы проверил: — повторный запрос после timeout; — два одинаковых запроса одновременно; — потерю соединения во время операции; — повторную отправку с тем же Idempotency-Key; — повторную отправку с новым ключом.

Особенно интересен случай с двумя запросами, пришедшими практически одновременно. Здесь уже можно столкнуться с race condition, когда обе операции успевают пройти проверку до того, как система зафиксирует результат первой. И тогда вопрос «что будет, если дважды нажать кнопку?» перестаёт быть вопросом UI.

Это уже вопрос API, конкурентного выполнения и целостности данных. А вы проверяете такие сценарии при тестировании API? 👇