Выгрузка из API дошла до середины и остановилась с ответом 429 Too Many Requests. Если сразу запустить её заново, ошибка может повториться ещё раньше: предыдущая попытка уже израсходовала часть доступных запросов. Если просто пропустить неудачные страницы, получится файл, который выглядит законченным, хотя часть каталога в него не попала.
Задача интеграции в такой ситуации состоит из двух частей: соблюдать ограничения источника и не потерять сведения о том, какие данные удалось получить. Разберём, что стоит проверить до изменения частоты запуска.
Сначала выяснить, какой лимит сработал
Код 429 означает превышение допустимого количества запросов за определённое время. Сервер может приложить заголовок Retry-After, но не обязан это делать. Сам код не сообщает, считается ли ограничение по аккаунту, токену, адресу или отдельному ресурсу. Это описано в RFC 6585.
Поэтому первая полезная запись в журнале выглядит не как «поставщик недоступен», а как набор проверяемых обстоятельств: время ответа, метод API, статус, идентификатор запуска и наличие рекомендации о повторе. Секретный токен, содержимое авторизации и персональные данные в такой журнал помещать не нужно.
Допустим, два отдела используют один ключ поставщика. Закупки обновляют остатки, а интернет-магазин в это же время получает цены. Ограничение проявляется в одном процессе, но учитывать приходится общую нагрузку. Уменьшение частоты только у закупок не объяснит картину без сведений о втором потребителе.
Как прочитать Retry-After
Заголовок допускает два формата: количество секунд ожидания и HTTP-дату. Эти варианты определены в HTTP Semantics. Число 120 здесь означает паузу в 120 секунд, а не время суток и не число разрешённых запросов.
Если в документации источника есть дополнительные ограничения, их тоже учитывают. Например, окончание короткой паузы ещё не означает, что восстановилась дневная квота. При HTTP-дате нужно корректно работать со временем и часовыми поясами, иначе повтор может уйти раньше указанного момента.
Ниже учебная схема принятия решения, а не настройки конкретного поставщика.
| Ситуация | Что сделать перед повтором |
|---|---|
| Есть корректный Retry-After | Дождаться указанного момента с учётом остальных ограничений API |
| Заголовка нет | Использовать согласованную политику пауз и проверить документацию источника |
| Ответ сообщает об исчерпанной дневной квоте | Перенести работу в разрешённое окно |
| Лимит непонятен и повторяется | Остановить серию попыток и уточнить условия доступа |
Почему одних пауз недостаточно
Представим учебный каталог из нескольких страниц. Первые страницы получены, на следующей пришёл 429. Сценарий ждёт и повторяет запрос. Но за время ожидания поставщик добавил товары, а выдача сортируется по времени обновления. Если продолжить старый номер страницы без учёта правил API, некоторые позиции могут встретиться дважды или остаться между страницами.
Здесь нужен отдельный разбор контракта пагинации. Если источник предоставляет курсор, снимок или параметр версии, используйте их по документации. Если устойчивого способа продолжения нет, безопаснее обозначить результат как неполный и выполнить новый согласованный сбор, чем считать любой полученный файл полным каталогом.
Для своего процесса заранее определите, какие промежуточные данные можно сохранять и когда их разрешено передавать дальше. Ошибка доступа не должна незаметно превращаться в нулевой остаток товара.
Повторы должны когда-нибудь заканчиваться
Бесконечный цикл с паузой удобен только до первого зависшего задания. Для рабочего процесса задайте число попыток, предельное время ожидания и дальнейшее действие. Это ваши эксплуатационные правила, а не универсальные числа для любого API.
Полезно разделить три исхода: источник временно ограничивает запросы, источник запретил доступ, ответ получить удалось, но данные не прошли проверку. Обрабатывать их одинаковым повтором не стоит. При отказе в доступе проверьте права и способ подключения; увеличивать частоту или менять аккаунты ради обхода ограничения не нужно.
Если несколько ваших заданий ждут одновременно, распределите повторные обращения во времени. Иначе после общей паузы они снова создадут тот же пик. Конкретный интервал выбирают по условиям источника и допустимой задержке бизнеса.
Что считать успешным восстановлением
Зелёный статус последнего HTTP-запроса ещё не подтверждает готовность всего результата. Перед передачей файла проверьте, что пройдены все нужные страницы, не потерялись обязательные поля и отсутствуют необъяснённые дубли. Если у поставщика есть достоверное общее количество, сопоставьте его со своим результатом.
В Akmelo разбор удобно начинать с журнала конкретного прогона и его результата. Настройка поведения при 429 зависит от сценария и используемого API. Сам факт запуска через платформу не обещает автоматическое соблюдение неизвестной квоты поставщика.
До следующей выгрузки договоритесь с владельцем процесса о простом правиле: что он увидит, если к нужному часу получена только часть данных. Явный статус «обновление не завершено» позволяет принять решение. Молчаливо выданная неполная таблица оставляет решение на волю случая.
