РУКОВОДСТВО · ОБНОВЛЕНО 2026-09-16
Как повторить запрос к нейросети после таймаута без двойного расхода
Когда клиент перестал ждать, сервер мог уже получить ответ модели и списать расход. Новый запрос с новым ID создаёт риск второй генерации.
До отправки сохраните уникальный идентификатор операции вместе с телом запроса. Если соединение оборвалось, сначала проверьте статус исходной операции. Там, где API гарантирует идемпотентный повтор, отправьте то же тело с тем же Idempotency-Key. Новый ключ нужен только для новой задачи; изменение модели, prompt или параметров делает запрос другой операцией.
1. Пройдите сценарий потерянного ответа
Пользователь попросил составить отчёт. Ваш сервис отправил запрос модели, но через 30 секунд соединение оборвалось. Возможны три состояния: запрос не дошёл, генерация ещё идёт или результат уже готов, а ответ потерялся. По одному сетевому исключению различить их нельзя. Если сразу выдать новый ID и повторить запрос, система может оплатить два ответа и показать только второй. Именно такую неопределённость должен учитывать обработчик.
2. Создайте ключ перед первой попыткой
Сгенерируйте случайный ID операции и сохраните его рядом с точным JSON-телом, пользователем, моделью и временем. Для Tokenmost платные методы в текущем контракте требуют заголовок Idempotency-Key длиной 8–128 символов. Повтор того же действия использует этот же ключ. Если пользователь изменил вопрос, модель или настройки генерации, это новая операция с новым ключом. Не выводите сам секретный API-ключ в журнал, а ID операции можно использовать для поиска события.
3. Не меняйте тело при повторе
Одинаковый Idempotency-Key с другим prompt или max_tokens нарушает смысл ключа и должен отвергаться сервером. Сериализацию тела лучше сохранить до первой отправки, чтобы фоновые воркеры не добавили другую историю диалога между попытками. Если клиентская библиотека автоматически повторяет запросы, проверьте, какие заголовки она сохраняет и не запускает ли параллельную попытку. Правила срока хранения результата и конфликта ключа зависят от конкретного API — их нельзя переносить из одного сервиса в другой.
4. Сверьте итог до нового вызова
Если метод даёт статус операции или журнал запросов, запросите его по вашему ID. При сохранённом результате верните его пользователю без нового вызова модели. При подтверждённом отказе действуйте по коду ошибки. При неизвестном состоянии повторяйте с тем же ключом только если контракт обещает безопасный replay; иначе остановите автоматизацию и покажите «результат требует сверки». Потоковый ответ и отмена требуют отдельной проверки, потому что частично полученный текст ещё не объясняет итоговое списание.
5. Проверьте конкурентные попытки
Сымитируйте потерю ответа после выполнения, одновременный повтор двух воркеров и изменение JSON при старом ключе. Ожидайте один логический результат либо явный конфликт, а не два списания. Сверьте журнал, usage и пользовательский ответ. Служба поддержки API должна уметь искать ID операции и отличать подтверждённый результат от временно неопределённого. Внешний replay проверяйте сквозным тестом перед рабочим запуском.
Частые вопросы
Можно просто увеличить таймаут?
Это уменьшит часть ложных сбоев, но не устранит потерю соединения и неизвестный итог запроса.
Нужен новый ключ для каждой попытки?
Нет. Один логический запрос сохраняет один Idempotency-Key; новый вопрос получает новый ключ.
Что будет при изменении тела с тем же ключом?
Такой запрос должен считаться конфликтом или отклоняться по правилам конкретного API.
Идемпотентность доступна во всех AI API?
Нет. Проверьте контракт выбранного сервиса, включая срок хранения результата и поведение при параллельных попытках.