Форма показала ошибку, человек нажал "Отправить" ещё раз, и менеджер получил две одинаковые заявки. Такое возможно даже при одном аккуратном повторе. Причина бывает в потерянном ответе сервера, поэтому отключённой на время кнопки для защиты недостаточно.

Разберём учебный пример. Сайт отправил запрос на создание заявки. Сервер сохранил её, но ответ не дошёл до браузера. Истекло время ожидания, и на экране появилась ошибка. Повторная отправка снова запускает создание, если сервер не умеет распознавать эту же операцию.

Тайм-аут сообщает, что клиент вовремя не получил ответ. По нему одному нельзя установить, выполнилась ли работа. Тот же вопрос возникает у автоматизации, которая повторяет запрос после сбоя связи.

Как сервер узнаёт повтор

Для таких операций применяют идемпотентность: несколько одинаковых запросов должны давать тот же предусмотренный эффект, что один. При этом ответы могут различаться. MDN отдельно отмечает, что у метода POST, которым часто отправляют формы, такой гарантии по умолчанию нет.

Один из способов защиты описан в Amazon Builders' Library. Клиент присваивает операции уникальный ключ и сохраняет его для повторов. Сервер связывает ключ с отправителем и результатом. Когда приходит повторный запрос с тем же ключом, он может вернуть результат уже выполненной операции, не создавая ещё одну заявку.

Новая самостоятельная заявка получает новый ключ. При повторе прежней отправки ключ остаётся прежним. Если генерировать его заново при каждой попытке, сервер будет видеть отдельные операции. Совпадение полей формы тоже ненадёжно: человек может намеренно отправить две одинаковые заявки.

Нужны правила на стороне сервера. Следует согласованно сохранять сведения о ключе и изменениях, учитывать одновременные запросы, проверять совпадение параметров и определить срок хранения ключа. Добавить произвольный заголовок в запрос недостаточно: API должен поддерживать такую обработку. После истечения срока прежняя защита может уже не действовать.

Что проверить в своём проекте

Я бы включил в проверку формы учебный сценарий на тестовом стенде: заявка сохраняется, первый ответ намеренно теряется, затем приходит повтор с тем же ключом. Ожидаемый результат нужно проверить в хранилище: создана одна заявка, клиент получил понятный статус.

Отдельно стоит проверить две одновременные попытки, тот же ключ с изменёнными данными и повтор после истечения срока хранения. Поведение последних двух случаев должно соответствовать договорённостям вашего API. Это предлагаемый план проверки, результаты испытаний здесь не приводятся.

Если готовый сервис не документирует защиту повторов, перед автоматическим повторным созданием стоит выяснить статус первой операции. Пауза между попытками сама по себе дубли не устраняет. Блокировка кнопки во время отправки полезна, но серверную логику всё равно нужно проверить.

Основа разбора: справка MDN об идемпотентности, HTTP Semantics RFC 9110 и материал Amazon Builders' Library о безопасных повторах API.

#ВебРазработка #Автоматизация #Тестирование

Где вам встречались дубли после повторной отправки: в заявках, уведомлениях или фоновых задачах?