Перейти к основному содержимому

Ошибки, лимиты частоты и надёжность

Средний
What you'll learn
  • Прочитайте карту HTTP-ошибок и знайте, какие статусы повторять, а какие исправлять
  • Повторяйте временные ошибки с экспоненциальной задержкой и джиттером, с ограничением
  • Обрабатывайте лимиты частоты с помощью retry-after, сглаживания, пакетной обработки и более дешёвых моделей
  • Изолируйте свой код от устаревания и миграции моделей

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

Карта ошибок

Типичные HTTP-статусы, которые вам придётся обрабатывать:

СтатусЗначениеЧто делать
400Некорректный запросИсправьте полезную нагрузку; не повторяйте как есть
401Неверный/отсутствующий API-ключПроверьте учётные данные
403Не разрешеноПроверьте доступ/разрешения
429Превышен лимит частотыСделайте задержку и повторите (соблюдайте retry-after)
500/529Ошибка сервера / перегрузкаПовторите с задержкой
Pro tip
  • SDK представляют их как типизированные исключения, так что вы можете чисто ветвиться, а не разбирать строки.

Повторы с задержкой

При временных ошибках (429, 5xx) повторяйте с экспоненциальной задержкой + джиттером, с ограничением:

import time, random
for attempt in range(5):
try:
return client.messages.create(...)
except (RateLimitError, APIStatusError) as e:
if attempt == 4 or not should_retry(e):
raise
time.sleep(min(2 ** attempt + random.random(), 30))
Watch out
  • Многие SDK повторяют временные ошибки автоматически — узнайте поведение вашего клиента по умолчанию, прежде чем добавлять собственное, иначе вы можете удвоить число повторов.

Лимиты частоты

Лимиты применяются на уровне аккаунта/тарифа (запросы и токены в минуту). При достижении лимита вы получаете 429 с подсказками о таймингах. Стратегии, чтобы оставаться под потолком:

Guided walkthrough1 of 4
  1. Когда вы получаете 429, прочитайте подсказку о тайминге в ответе и подождите столько времени, прежде чем повторять.

См. Выбор модели для подбора правильной модели для объёмных шагов.

Миграция моделей

ID моделей датированы/версионированы и со временем устаревают. Защитите себя:

Key takeaways
  • 400/401/403 — это ваша вина: исправьте запрос или учётные данные, не повторяйте вслепую. 429 и 500/529 повторяемы.
  • Повторяйте временные ошибки с экспоненциальной задержкой + джиттером, с ограничением (например, min(2 ** attempt + random(), 30)).
  • При 429: соблюдайте retry-after, сглаживайте всплески, выполняйте офлайн-работу пакетно и направляйте объёмные шаги на более дешёвую модель.
  • Читайте ID моделей из конфигурации, следите за устареваниями и перезапускайте оценки при миграции моделей.

Проверь себя

0/4
  1. Вы получили 400 «Некорректный запрос». Что следует сделать?
  2. Какие статусы следует повторять с задержкой?
  3. Зачем добавлять джиттер к экспоненциальной задержке?
  4. Что НЕ является предложенной стратегией для лимитов частоты?

Далее