429, timeout и незавершённый запрос: безопасное восстановление
Какие данные сохранить при ошибке, когда можно повторять запрос и почему новый ID может создать новую платную работу.
Что проверено. JS/Python клиенты проверены на локальном HTTP mock: сохранение ID и тела, HTTP 202, подтверждённое списание и ошибка без вывода отладочного сообщения.
Это протокольная проверка. Внешний provider timeout и реальные платежи не запускались.
Сохраните идентичность до отправки
Файл или запись запроса должны содержать endpoint, точное тело и Idempotency-Key. API-ключ остаётся в защищённом хранилище. Случайный UUID, который создаётся внутри каждого retry, не защищает от второго платного вызова.
Скачиваемый quickstart записывает тело и ID один раз и отказывается перезаписывать существующий файл. Это позволяет повторить команду send после сбоя клиента. Для нового сообщения создайте отдельный файл и ID осознанно.
Разделите отказ и неизвестный исход
401 и 403 требуют проверки ключа и прав; 402 требует проверки доступного баланса и резервов. При 429 учитывайте лимит и Retry-After, если сервер его вернул. Эти сигналы не дают разрешения менять модель или расширять scope автоматически.
Timeout, обрыв SSE и HTTP 202 требуют особого внимания: поставщик мог уже принять работу. Используйте прежние ключ, endpoint, тело и Idempotency-Key. Проверяйте историю или ID задания; не объявляйте резерв возвращённым, пока это не подтвердил сервер.
Исходный запрос → сохранённый ID → повтор той же операции Подтверждённый результат → usage + billing Неизвестный исход → сохранённый резерв и сверка
Передайте для диагностики безопасный минимум
Запишите время, X-Request-Id, ID задания, endpoint, HTTP-статус и код ошибки. Не прикладывайте полный ключ, исходный документ или платёжные реквизиты к публичному issue. Чужой запрос нельзя искать по ID через свою организацию.
Если результат уже подтверждён, повтор возвращает сохранённое состояние. Если он неизвестен, новый ID не исправляет старый. Сначала завершите диагностику исходной работы, затем решайте, нужен ли пользователю отдельный новый запрос.
Источники и повторная проверка
При изменении API-контракта, доступных параметров, тарифа или версии клиента пример нужно проверить повторно. Редакционная правка сама по себе не подтверждает новый технический тест.