Кнопка крутится, вкладка показывает ошибку, а форма, которую вы заполняли десять минут, исчезла. Вы не знаете, успела ли запись пройти до обрыва связи. Именно отношение к этой неизвестности как к провалу и создаёт дубли комментариев, двойные заказы и повторные обращения в поддержку.

Восстанавливайте в строгом порядке: сохраните текст, найдите результат и только потом решайте, допустимо ли второе отправление.

Начните с текста и отметки времени

Скопируйте содержимое со страницы, прежде чем трогать что-либо ещё, включая черновик, который браузер всё ещё держит в поле. Запишите время, страницу, на которой вы были, и выполненное действие, потому что именно эти три детали делают возможным остальное расследование. Если вкладка ещё открыта, оставьте её открытой, пока не прочитаете запись в сети. Сохранить текст ничего не стоит, а потерять его — значит потерять всю задачу.

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

Ищите результат в собственном представлении приложения

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

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

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

Решите, безопасно ли повторное отправление

Ответ зависит от операции, а не от вашего терпения. HTTP отделяет методы, которые можно повторять с тем же предполагаемым эффектом, от тех, которые нельзя, и не советует автоматически повторять вторые, если не известно, что семантика это позволяет. Создание комментария, оформление заказа и отправка платежа обычно относятся ко второй группе, поэтому второй внешне успешный щелчок ничего не говорит о первом.

Если вы поддерживаете клиент, используйте механизм повторных попыток или идемпотентности, который документирует API, и привязывайте его к той же логической операции, а не создавайте новый ключ для каждой попытки. Идентификатор запроса для трассировки не является ключом подавления дубликатов, если сервер не относится к нему как к таковому.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

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

Соберите доказательства, прежде чем снова что-то нажимать

Сохраните запись сети, а не снимок экрана с ошибкой. Метод запроса, URL, ответ или тайм-аут и время, когда это произошло, — это то, что администратор может соотнести с записями приложения. Экспортируйте или скопируйте запись как команду только если затем удалите из копии файлы cookie, заголовки авторизации и любое приватное содержимое. Оставьте собственную сессию нетронутой и никогда не воспроизводите перехваченный запрос с учётными данными как короткий путь.

Задайте владельцу сервиса один конкретный вопрос: удалась ли операция с этим содержимым в это время и есть ли на неё ссылка? У этого вопроса есть ответ, а у "сломался ли сайт" его нет.

Смысл упражнения — установить, что действие произошло ровно один раз. Сообщение об ошибке, которое можно закрыть, не то же самое, что запись, которой можно доверять, и именно второе нужно вам, прежде чем отправлять что-либо ещё.

Похожие статьи