ChatGPT API: retry после 429 без повторных действий

Разделите 429 и бизнес-результат

HTTP 429 означает, что текущий путь не принял запрос в наблюдаемом окне. Он не сообщает точный лимит, баланс, причину политики или момент следующего успеха. Сначала сохраните локальный operation ID и категорию ответа, затем верните пользователю нейтральное состояние ожидания либо остановки.

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

Повторяйте только идемпотентный участок

Backoff применим к чтению или к локальной подготовке, если повтор не меняет внешний мир. Для команды с побочным эффектом добавьте локальный ключ идемпотентности и храните результат по своему operation ID. Не используйте клиентский timestamp как единственный ключ: он плохо защищает от двойного клика и повторной доставки.

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

Сделайте задержку наблюдаемой

Для каждой попытки фиксируйте только минимум: внутренний ID, номер попытки, нормализованную категорию, длительность и решение policy. Не записывайте prompt, заголовки, ключи или полный ответ. Эти данные позволяют увидеть всплеск 429 и проверить собственный backoff, не превращая журнал в архив пользовательских данных.

Добавьте случайный разброс к задержке, чтобы одновременно проснувшиеся клиенты не создали новый всплеск. Конкретные значения выбираются вашей командой и тестируются на синтетической нагрузке; статья не устанавливает лимиты RussiaAPI или внешнего провайдера. При смене SDK повторите тест, потому что классификация ошибок может измениться.

Тестируйте неизвестный итог до релиза

Проверьте искусственные ответы 429, обрыв после отправки, повтор одного operation ID и истечение локального дедлайна. Ожидаемый результат теста — не максимум повторов, а предсказуемая остановка: сервер либо возвращает ранее сохранённый исход, либо просит review без второго внешнего действия.

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

Сначала зафиксируйте границу решения

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

Проверяйте правила на синтетических значениях. Не кладите в fixture настоящий prompt, пользовательское вложение, cookie, авторизационный заголовок или ключ. Для технической записи обычно достаточно времени, версии адаптера, внутреннего operation ID, категории исхода и хэша нормализованной структуры. Это позволяет искать регрессии, не превращая журнал в копию пользовательских данных.

Проверяйте контракт небольшим сценарием

Минимальный контрактный тест должен различать корректный ответ, ошибку валидации, отказ локальной policy, временную сеть и неизвестный итог. Для каждого состояния заранее назначьте действие: безопасно остановить, повторить только идемпотентную операцию или передать её на review. Бесконечный retry не исправляет несовместимый формат и не доказывает, что внешнее действие не случилось.

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

Минимизируйте технические данные

Не делайте секрет, полный пользовательский текст, исходный media URL или сырой ответ модели стандартным полем лога. Отделите понятное сообщение для пользователя от защищённой server-side записи. Доступ к журналам ограничьте ролями, а срок хранения определите локальной политикой и классификацией данных, а не предположением о правилах поставщика.

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

Оставьте обратимый путь

Новый routing rule, обработчик webhook или набор параметров включайте так, чтобы его можно было отключить без изменения пользовательских данных. Сохраните известный безопасный сценарий, критерий остановки и короткую запись решения. При неясном статусе направляйте операцию на review вместо повторной отправки, публикации результата или автоматического побочного действия.

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

Разделите локальную policy и внешний сервис

Локальная allowlist, лимит очереди, ручная проверка и журнал — это функции вашего приложения. Они не равны каталогу моделей, внешнему rate limit, остаткам, SLA или сертификации поставщика. Такое разделение делает ответ пользователю честным: приложение управляет собственным риском, а свойства маршрута нужно подтверждать отдельно в актуальном каталоге, договоре и документации.

Ключ RussiaAPI используйте только на сервере через переменную окружения или совместимое хранилище секретов. Не переносите в новый gateway чужой ключ, cookie или Authorization header. Перед реальным запросом подтвердите доступный маршрут и model ID в своём аккаунте; пример ниже намеренно не вызывает сеть и не доказывает поддержку endpoint.

Планируйте отрицательные тесты

Happy path полезен, но не показывает, как система поведёт себя при пустом идентификаторе, неизвестном параметре, повторном событии, обрыве клиента или устаревшей версии policy. Добавьте такие случаи до релиза. Если проверка не может определить безопасный итог, верните локальную понятную ошибку или запросите review, а не пытайтесь угадать состояние задачи.

Регулярно пересматривайте владельца policy, тестовую дату и условия rollback. Чем проще структура решения, тем легче обнаружить изменение контракта. Не записывайте для этого полный prompt и не расширяйте права «на всякий случай»: наблюдаемость должна помогать разбирать проблему, а не создавать новую поверхность утечки.

Server-side пример без сетевого вызова

Пример демонстрирует только локальную проверку приложения. Он не содержит настоящего ключа, не вызывает сеть и не подтверждает конкретный endpoint. Для реальной интеграции используйте собственный ключ RussiaAPI на сервере через RUSSIAAPI_API_KEY и предварительно сверяйте текущий каталог и контракт.

function decideRetry({ operationId, attempt, status, hasSideEffect, knownResult }) {
  if (!operationId) return { ok: false, code: 'operation_id_required' };
  if (knownResult) return { ok: true, action: 'return_saved_result' };
  if (status !== 429) return { ok: false, action: 'review', code: 'unknown_outcome' };
  if (hasSideEffect || attempt >= 3) return { ok: false, action: 'review', code: 'retry_not_safe' };
  return { ok: true, action: 'retry_local_safe_step', delayMs: 500 * (attempt + 1) };
}

Проверьте синтаксис через node --check, добавьте аутентификацию своего маршрута и негативные тесты. Не логируйте тело запроса или заголовки лишь ради отладки.

Источники для дальнейшей проверки

• Google SRE: Addressing Cascading Failures
• IETF: The Idempotency-Key HTTP Header Field

Ссылки дают общий инженерный контекст. Перед production-изменением сопоставьте их со своим договором, текущим каталогом RussiaAPI и тестом конкретного маршрута.

FAQ

Читайте также

• Idempotency key для повторов
• Локальный бюджет токенов
• Бюджет дедлайна API