Ограничьте повторения HTTP дедлайном и обрабатывайте неизвестные результаты

Интерпретируйте Retry-After перед планированием

Retry-After может содержать неотрицательное количество секунд или HTTP-дату. Задержка в секундах измеряется после получения ответа. HTTP-даты требуют сравнения с текущим временем и могут зависеть от разницы часов. Отсутствующее или некорректное значение не разрешает бесконечное или немедленное повторение.

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

Бюджетируйте всю операцию

Таймаут на одну попытку ограничивает один запрос. Общий дедлайн ограничивает операцию через попытки и периоды ожидания. Запуск свежего таймаута в десять секунд для каждого повторения может превратить задуманную операцию в десять секунд в гораздо более длительную.

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

Поймите механизм таймаута

В браузерах AbortSignal.timeout измеряет активное время. Это время может приостанавливаться, пока воркер приостановлен или документ находится в кэше обратно-вперед. Не описывайте его как универсальный дедлайн по стене часов.

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

Решите, какие запросы можно повторять

HTTP-идемпотентность описывает предполагаемый эффект повторения идентичного запроса. Безопасные методы, такие как GET, идемпотентны, и PUT и DELETE также идемпотентны по своей определенной семантике. Это не означает, что каждое повторение возвращает тот же статус или что конкретная реализация сервера корректна.

Не автоматически повторяйте каждый неуспешный ответ. Постоянная ошибка валидации не должна попадать в ту же политику, что и временный сбой сервиса. POST и PATCH не гарантированы как идемпотентные, поэтому неизвестный результат требует конкретного контракта согласования или дедупликации API.

HTTP/1.1 503 Service Unavailable
Retry-After: 120

Отслеживайте одну согласованную временную шкалу

Предположим, гипотетическая операция начинается в нулевого времени с дедлайном в десять секунд. Попытка 1 терпит неудачу, и выбранный бэкофф позволяет начать попытку 2 в три секунды. В этом примере предположим, что ответ 503 получен в то же время со значением Retry-After: 120.

Остается семь секунд, но запрошенное ожидание составляет 120 секунд. Ожидаемое решение - остановиться с причиной, такой как retry_after_exceeds_deadline. Третьей попытки нет. Это построенные значения, используемые для объяснения решения, а не измерения из сетевого теста.

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

Ограничьте бэкофф и количество попыток

Когда API разрешает повторение и не предоставляет пригодного значения Retry-After, политика бэкоффа с ограничением может распределять попытки во времени. Джиттер варьирует периоды ожидания, чтобы избежать одновременного прибытия синхронизированных клиентов. Определите ограничение, случайность и максимальное количество попыток как политику приложения, а не утверждайте, что стандарт HTTP предоставляет один универсальный алгоритм.

Перед сном проверьте, оставляет ли выбранное ожидание достаточно времени для полезной следующей попытки. Остановитесь, когда это не так. Большое значение Retry-After - причина отказаться от короткой операции, а не причина ограничить запрошенное сервером ожидание и повторить раньше его истечения.

Согласуйте неизвестный результат записи

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

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

Записывайте причину каждого решения

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

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