Ошибка HTTP 429 Too Many Requests: Retry-After и безопасные повторы

Определите, какой компонент вернул 429

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

Лимит может относиться к IP-адресу, пользователю, приложению или отдельному ресурсу. Тело ответа и панель поставщика иногда указывают исчерпанную квоту. Ограничение частоты, количества одновременно выполняющихся запросов и суточного объёма требуют разных решений. Замедление очереди не восстановит уже израсходованную суточную квоту.

• Нагрузка выросла из-за новых заданий или из-за повторов одного задания?
• Делят ли несколько сервисов, вкладок или API-ключей одну квоту аккаунта?
• Ограничивается число запросов, активных соединений, токенов или другой ресурс?
• Укладывается ли время восстановления в допустимый срок действия пользователя?

Правильно прочитайте Retry-After

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

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

Рассчитайте общую очередь и одновременную нагрузку

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

Выберем рабочую цель 90 запросов в минуту, оставив запас для других задач. Это 1.5 запроса в секунду, или примерно 667 миллисекунд между запусками. Для 600 запросов получается около 400 секунд без учёта дополнительных задержек и повторов. Это расчёт планирования, а не гарантия соответствия любому скользящему окну поставщика.

При среднем ответе за две секунды закон Литтла даёт около 1.5 × 2 = 3 одновременно выполняющихся запросов в устойчивом режиме. Семафор ограничивает активные операции, а общий ограничитель частоты разносит моменты запуска. Эти механизмы решают разные задачи; повторные попытки расходуют ту же квоту, что и первые.

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

Добавьте ограниченную задержку и случайный разброс

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

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

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

Повторяйте только операции с понятной безопасностью

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

SDK иногда повторяет запросы самостоятельно. Дополнительный внешний цикл способен умножить число сетевых обращений. Зафиксируйте общий предел по всем слоям. Для действия пользователя лучше показать понятное состояние «повторить позже», чем скрывать длинную очередь за постоянно вращающейся кнопкой.

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

Проверьте исправление на небольшом контролируемом пакете

Начните с небольшого известного числа чтений и отдельно посчитайте первые попытки, повторы, успешные ответы и конечные отказы. Проверьте фактические интервалы и число активных операций. Затем воспроизведите искусственный ответ 429 с известным Retry-After, не перегружая живой сервис повторными экспериментами.

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