Codex “stream disconnected before completion” — điều gì đã kết thúc stream và Codex tự retry những gì

Đọc lý do sau dấu hai chấm

Codex dùng cùng một lỗi này cho stream kết thúc sớm mà không có chẩn đoán cụ thể hơn, rồi nối thêm lý do. Trong mã nguồn, stream chỉ đơn giản kết thúc sẽ cho “stream closed before response.completed”; stream im lặng lâu hơn stream_idle_timeout_ms sẽ cho “idle timeout waiting for SSE” (“idle timeout waiting for websocket” trên transport WebSocket mà built-in OpenAI provider sử dụng); yêu cầu bị lỗi trên đường truyền giữ nguyên cách diễn đạt của HTTP client, “error sending request” (các bản build trước 0.156 có thêm URL); còn sự kiện response.failed chung đặt thông báo của server sau dấu hai chấm. Từ Codex 0.148, kết nối hoàn toàn không thể mở — DNS, TLS, port bị từ chối — được báo dưới dạng lỗi riêng, “Connection failed”, và các bản build hiện tại tiếp tục retry trong khi chờ mạng.

stream closed before response.completed  the connection ended with no terminal event:
                                         network path, server, or a provider that
                                         never sends response.completed
idle timeout waiting for SSE             no event for stream_idle_timeout_ms
error sending request                    the request broke on the wire: a reset, a
                                         proxy or a middlebox (before 0.148, also
                                         a connection that never opened)
…error decoding response body            the body broke mid-read: network or middlebox
An error occurred while processing…      the server's own response.failed message
Incomplete response returned, reason: …  the server stopped it: a token cap, a content
                                         filter, or whatever the reason names

Biết Codex đã retry những gì và điều chỉnh theo từng provider

Có hai ngân sách retry. request_max_retries (mặc định 4) áp dụng cho yêu cầu HTTP trước khi bất kỳ stream nào tồn tại; Codex retry phản hồi 5xx và lỗi transport ở đó, nhưng không retry 429. stream_max_retries (mặc định 5) bao phủ mọi thứ trên trang này: mỗi lần retry gửi lại lượt, được đếm bởi “Reconnecting... 1/5”, và khi hết ngân sách, lỗi vẫn hiển thị trên màn hình còn lượt bị dừng. Cả hai đều bị giới hạn ở 100 và cùng nằm trong block [model_providers.<id>]. ID provider openai tích hợp sẵn được dành riêng và không thể định nghĩa lại, vì vậy đây là các tùy chọn dành cho provider tùy chỉnh.

model = "gpt-5-6-sol"
model_provider = "kunavo"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"
# wire_api defaults to "responses", the only supported value
stream_max_retries = 10          # dropped or failed streams (default 5, max 100)
request_max_retries = 4          # 5xx and network errors before streaming (default 4, max 100)
stream_idle_timeout_ms = 300000  # silence before giving up (default 300000)

Tái hiện stream mà không dùng Codex

Một stream Responses kết thúc bằng một sự kiện đầu cuối, và Codex cần đó là response.completed. Gửi cùng loại yêu cầu bằng curl từ cùng máy. Nếu nó luôn hoàn tất trong khi Codex tiếp tục ngắt kết nối, hãy kiểm tra bản build Codex và các issue đang mở; nếu curl cũng lỗi, thử lại từ mạng khác trước khi đổ lỗi cho provider. Ghi lại thời điểm lỗi xảy ra: việc ngắt ở cùng thời gian đã trôi qua trong mọi lần chạy chỉ ra một bộ hẹn giờ ở đâu đó trên đường truyền, không phải mạng chập chờn.

curl -sN https://api.kunavo.com/v1/responses \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5-6-sol","stream":true,
       "input":"Write a 600-word story about a lighthouse keeper."}' \
  | grep -oE '"type": ?"response\.(completed|failed|incomplete)"'
# a healthy run prints exactly one line: "type":"response.completed"

Loại mạng khỏi nguyên nhân, rồi kiểm tra provider

Hãy kiểm thử từ mạng thứ hai trước khi kết luận. Trên diễn đàn OpenAI, lỗi của một người dùng trên máy làm việc biến mất ngay khi họ tắt Zscaler của công ty; trong một thread GPT-5.6, lỗi của một người dùng được khắc phục khi dùng VPN hoặc hotspot điện thoại, trong khi lỗi của người khác vẫn tồn tại sau khi đổi mạng. Nếu mạng khác khắc phục được, hãy loại trừ API host khỏi proxy hoặc kiểm tra TLS thay vì tăng timeout. Với provider tùy chỉnh, codex doctor cho biết config có được tải hay không và biến key của provider có hiện diện hay không; provider phải cung cấp Responses API, vì wire_api không có giá trị nào khác, còn supports_websockets nên để trống trừ khi nó chạy transport Responses WebSocket. Nếu curl hoàn tất sạch sẽ mà Codex vẫn lỗi, hãy thêm trường hợp tái hiện của bạn vào các issue openai/codex #41340 hoặc #41989, trong đó báo cáo lỗi này với các provider Responses tùy chỉnh stream đúng bên ngoài Codex và vẫn đang mở vào ngày 23 tháng 9, 2026.

“stream closed before response.completed” có nghĩa là gì?

Phản hồi HTTP đã bắt đầu, sau đó kết nối kết thúc mà không có event response.completed mà Codex chờ đợi. Có thứ gì đó đã đóng nó sớm: proxy hoặc firewall trên đường truyền, server hoặc endpoint tùy chỉnh không bao giờ gửi event đó.

Codex có tự động retry “stream disconnected before completion” không?

Có. Codex gửi lại lượt tối đa stream_max_retries lần (mặc định 5, tối đa 100) và hiển thị Reconnecting... 1/5 trong lúc thực hiện. Khi hết ngân sách, lỗi vẫn hiển thị trên màn hình và lượt dừng; gửi message khác sẽ bắt đầu yêu cầu mới.

Tôi có nên tăng stream_idle_timeout_ms không?

Chỉ khi lý do là “idle timeout waiting for SSE” và khoảng im lặng đó là hợp lệ. Việc này không có tác dụng với “stream closed before response.completed”, khi kết nối đã kết thúc thay vì trở nên im lặng. Thông qua Kunavo, các giá trị lớn hơn 300000 không đem lại lợi ích sau khi stream bắt đầu: Kunavo ngừng đọc upstream không gửi gì trong 300 giây và kết thúc stream của bạn.

Tại sao Codex báo “Incomplete response returned, reason: max_output_tokens”?

Server đã dừng phản hồi ở giới hạn token và báo điều đó bằng event response.incomplete. Codex báo lỗi dưới cùng dạng này và retry, nhưng retry cùng lượt thường lại gặp đúng giới hạn, vì vậy hãy chia nhỏ tác vụ hoặc dùng mô hình có giới hạn output lớn hơn. Thông qua Kunavo, việc dừng do max-token của mô hình Claude đến Codex theo cùng cách.

Tôi có bị tính phí cho các lần retry không?

Mỗi lần retry là một yêu cầu mới. Thông qua Kunavo, lệnh gọi GPT bị lỗi ở upstream — lỗi trước khi stream, response.failed hoặc kết nối bị ngắt — được ghi nhận với chi phí bằng 0. Một lần thử mà Codex đã bỏ cuộc trong khi upstream vẫn tiếp tục hoạt động sẽ bị tính phí cho phần mà upstream báo đã tạo ra, vì công việc đó đã được thực hiện.