· reAPI Team
stream disconnected before completion: stream closed before response.completed
Codex достиг конца потока, не приняв событие завершения. Перед повтором проверьте полный текст ошибки, конечное событие, тайм-аут и протокол конечной точки.
«stream disconnected before completion: stream closed before response.completed» означает, что Codex дошёл до конца потока ответа, не приняв событие завершения. Сообщение указывает, где остановилась обработка, но не определяет, какая машина стала причиной сбоя. В SSE-обработчике Codex, изученном 22 октября 2026 года, это резервная ошибка при конце потока; ошибки транспорта, тайм-ауты бездействия и ранее полученные серверные ошибки обрабатываются отдельно.[1]
Прочитайте полный текст после основного сообщения, прежде чем менять настройки. Для закрытого потока нужна трассировка событий, для тайм-аута бездействия — временные измерения, для ограничения скорости — сведения об ограничиваемом ресурсе. Если оцениваете reAPI, сначала изучите документацию запросов GPT-6 Astra: там описан Chat Completions. Успешный запрос Chat Completions не доказывает совместимость с протоколом Responses, который использует Codex.[2][3]
С чего начать
- Перед повтором сохраните полную ошибку, версию клиента, время и идентификатор запроса. Не включайте секретные данные и приватные промпты в общие отчёты.
- При преждевременном закрытии проверьте, содержат ли полученные SSE-данные корректное принятое завершающее событие. Одного успешного HTTP-статуса или видимого текста недостаточно.[1]
- При
idle timeout waiting for SSEизмерьте интервалы между событиями. Документированная настройка бездействия отделена от количества повторов запросов и потоков.[2] - При временном ограничении следуйте подсказке сервиса о повторе и снижайте соответствующую нагрузку. Ошибки квоты или оплаты требуют действий с аккаунтом.[4]
stream disconnected before completion: stream closed before response.completed
Исходный код позволяет сделать более узкий вывод, чем «у вас сломан интернет». Цикл SSE читает события, десериализует их JSON и передаёт распознанные события обработчику Responses. Когда тот возвращает завершённый ответ, цикл успешно заканчивается. Если входной поток заканчивается раньше, возвращается сохранённая ошибка ответа, когда она есть; иначе выдаётся сообщение о закрытом потоке.[1]
При разборе трассировки полезно различать следующие ситуации:
| Наблюдение | Что оно подтверждает | Следующий шаг диагностики |
|---|---|---|
| Текст пришёл, затем поток закончился | Часть вывода дошла до клиента | Найти завершающее событие и его JSON-тело |
| Успех HTTP, но завершение не принято | HTTP-запрос успешен на этом уровне | Проверить последовательность событий, а не считать задачу законченной |
| Есть данные, похожие на завершение | Пришли байты, напоминающие завершающее событие | Проверить тип события, обязательные поля ответа и парсер установленного клиента |
| Перед EOF сохранена серверная ошибка | Сервис сообщил об ошибке | Сначала разобрать её, а не считать закрытие отдельным сетевым сбоем |
Это интерпретации изученного парсера, а не результаты живого вызова reAPI. В статье используется неизменяемая ревизия c2d5ea52, чтобы вы могли сравнить её поведение со своим клиентом, не предполагая, что все версии Codex одинаковы.[1]
Некорректные данные требуют отдельной проверки. В этой ревизии событие, не прошедшее начальную десериализацию JSON, записывается в журнал и пропускается. Распознанное событие завершения с некорректным объектом ответа проходит по другой ветке ошибки. Поэтому наличие строки response.completed в журнале не доказывает, что Codex её принял. И наоборот, закрытый поток сам по себе не доказывает, что сервер не отправил событие: сравните отправленные сервером данные с полученными клиентом.[1]
Для собственного эндпоинта проверьте документированный протокол, прежде чем увеличивать число повторов. Текущая справка указывает responses как поддерживаемое значение wire_api, а поддержку WebSocket описывает как отдельную возможность провайдера. Сам по себе приём JSON в формате OpenAI Chat Completions не делает эндпоинт рабочим Responses-эндпоинтом.[2]
Предлагаемая последовательность воспроизведения невелика: один текстовый запрос, затем тот же запрос с потоковой передачей, затем взаимодействие с инструментом, которое изначально дало сбой. Не меняйте между шагами эндпоинт, ключ и модель. Записывайте изменения на каждом шаге: это способ диагностики, а не гарантия поддержки всех трёх тестов любым провайдером. Если тесты оплачиваются, выполняйте только те, которые разрешены для этого аккаунта.
stream disconnected before completion: transport error: network error: error decoding response body
Этот поисковый запрос описывает сбой транспорта или чтения тела ответа. SSE-обработчик Codex может вернуть ошибку входящего потока до получения следующего пригодного события. Это отличается от обычной ветки завершения потока, описанной выше.[1]
Рассматривайте отдельные компоненты как направления проверки, а не список доказанных причин. Запишите конечный хост эндпоинта, версию клиента, HTTP-статус при наличии, прошедшее время и факт получения событий ответа. Затем сравнивайте по одному контролируемому изменению: например, другой разрешённый сетевой маршрут или тот же эндпоинт вне проблемного клиента. Успешное открытие сайта в браузере не проверяет конкретный аутентифицированный поток, который оборвался.
Рекомендации OpenAI по ошибкам соединения API предлагают проверить сетевые настройки, прокси, SSL-сертификаты и правила межсетевого экрана. Это перечень проверок, а не диагноз конкретной строки ошибки в вашей среде.[5] Не отключайте проверку сертификатов. Если сеть управляется организацией, используйте утверждённую конфигурацию, а не посторонний обходной вариант с прокси.
Передавая инцидент оператору шлюза, приложите очищенную структуру запроса и тип последнего полученного события. Скриншот только со словом «disconnected» скрывает различие, нужное оператору. Полную трассировку сохраните локально; передавайте сокращённую версию без заголовков авторизации, приватного ввода и вывода инструментов.
stream disconnected before completion: idle timeout waiting for sse
Тайм-аут бездействия означает, что ожидание следующего SSE-события превысило настроенный интервал. Это не то же самое, что большая общая длительность ответа: долгий ответ с поступающими событиями имеет другой временной профиль, чем молчащий поток.[1]
Справка по конфигурации, проверенная 22 октября 2026 года, разделяет три настройки:[2]
| Настройка провайдера | Документированная область действия |
|---|---|
stream_idle_timeout_ms | Ожидание SSE-событий при бездействии, в миллисекундах |
stream_max_retries | Число повторов при разрывах SSE |
request_max_retries | Число повторов HTTP-запросов |
Увеличение интервала бездействия меняет время ожидания клиента. Оно не заставит несовместимый эндпоинт выдавать события Responses и не восстановит потерянные байты. Увеличение числа повторов меняет число попыток, а не причину первого сбоя.
Измерьте поведение до изменения значений. Зафиксируйте начало ответа, поступление каждого события и момент ошибки. Если наблюдаемая граница совпадает с тайм-аутом клиента, сопоставьте его с документированным поведением сервиса. Если соединение закрывается раньше, исследуйте это закрытие. Не назначайте универсальный тайм-аут всем моделям, сетям и шлюзам на основе одного неудачного хода.
rate limit exceeded: upstream rate limit exceeded, please retry later
Сообщение сообщает об ограничении где-то на пути запроса, но само по себе не определяет аккаунт, ограничиваемый ресурс или время сброса. Не выводите конкретного поставщика из слова «upstream» и не считайте, что покупка дополнительных кредитов исправит любое ограничение скорости.
Документация прямого API OpenAI различает лимиты запросов и токенов, временную перегрузку, а также условия квоты и расходов. В ней описаны заголовки ответа с лимитами и указано, что Retry-After, если он передан для временной ситуации, задаёт минимальное ожидание. Условия аккаунта, требующие действий, повторами не устраняются.[4] Это документированная семантика OpenAI; для реального запроса используйте документацию и заголовки того эндпоинта, к которому обращаетесь.
| Данные от реального эндпоинта | Подходящее действие |
|---|---|
| Временный лимит с подсказкой о повторе | Выждать не меньше указанного времени, затем повторить в рамках ограниченной политики |
| Исчерпана частота запросов | Снизить частоту у всех воркеров, разделяющих этот лимит |
| Исчерпана скорость расхода токенов | Проверить потребность в токенах вместе с числом запросов |
| Квота, оплата или потолок расходов | Решить проблему аккаунта до повторной отправки нагрузки |
| Общее сообщение без указания ресурса | Сохранить идентификатор запроса и попросить оператора определить ограничение |
OpenAI рекомендует экспоненциальную задержку со случайной составляющей при отсутствии подходящей подсказки и отмечает, что неуспешные запросы тоже могут учитываться в лимитах. Учтите повторы SDK перед добавлением ещё одного цикла в приложение.[4] Политика повторов должна иметь условие остановки и не превращать одну отклонённую задачу в бесконечный поток новых запросов.
Для задачи агента проверьте и уже выполненные действия. Прочитайте diff рабочего дерева и историю инструментов, прежде чем просить агента повторить прерванную операцию. Сбой финального ответа не доказывает сбой всех предыдущих действий инструментов. Такая сверка — эксплуатационный совет для предотвращения дублей, а не утверждение, что Codex автоматически откатывает внешние действия.
Why does my Codex stream disconnect before completion and the stream closed before the response is completed?
В изученной SSE-ветке клиент дошёл до конца входа, не вернув успешное завершение и не имея более конкретной сохранённой ошибки. Сравните полученную трассировку с трассировкой сервиса, чтобы определить, отсутствовало ли завершающее событие, было ли оно некорректным или потерялось по пути. Само сообщение не позволяет выбрать объяснение.[1]
Why does Codex keep disconnecting?
Повторяющиеся сбои требуют воспроизводимого сравнения: зафиксируйте версию клиента, модель и эндпоинт, сохраните полную ошибку и меняйте по одному условию. Сначала различите раннее закрытие, транспортную ошибку, тайм-аут бездействия и отказ сервиса. Увеличение повторов до этого может просто воспроизводить ту же ошибку без новых полезных данных.
codex request timed out
Определите компонент, сообщивший о тайм-ауте. В конфигурации провайдера Codex есть интервал бездействия SSE, но API-клиент также может сообщать о тайм-ауте запроса. Рекомендации OpenAI перечисляют сетевые и серверные факторы для проверки; тайм-аут не становится доказательством одной конкретной причины.[2][5]
resume stream unavailable
Не воспринимайте это как гарантию возможности продолжить ответ или доказательство потери всей завершённой работы. Запишите версию клиента и полную ошибку, сохраните разговор и проверьте выполненные действия инструментов. Изученные источники не подтверждают универсальную команду восстановления для этой точной строки, поэтому здесь такая команда не предписывается.
Если следующим шагом будет смена модели или эндпоинта, руководство по миграции GPT-6 Astra объясняет, как разделять обнаружение моделей, смену протокола и проверку инструментов. Текущее предложение reAPI представлено на странице модели. Ни имя модели, ни цена не заменяют успешную сквозную проверку совместимости с Codex.
Источники проверены 22 октября 2026 года
- OpenAI. Codex Responses SSE implementation, ревизия
c2d5ea52e1b7ab11ee2d71dc44ea1ef00f9c8eb3. Исходный код и сопутствующие тесты. - OpenAI. Configuration Reference, протокол провайдера, тайм-ауты и повторы. Справка по конфигурации.
- reAPI. Документация запросов GPT-6 Astra. Опубликованный контракт запросов; документация реализации проверена локально, без живого теста генерации.
- OpenAI. Rate limits, заголовки ответа и рекомендации по повторам. Лимиты API.
- OpenAI. Error codes, ошибки соединения API и тайм-ауты. Рекомендации по ошибкам API.