直接回答
stream は HTTP handshake 成功後にも失敗します。event 順序と終了状態を保持し、部分出力を完全な結果として扱わないようにします。
このガイドで解決できること
truncate、buffer、timeout、誤った consumer による SSE model stream の中断を修正する。
症状と影響範囲を確認する
stream が開始して部分出力を返した後、正常な completion event や finish reason なしで停止します。
同じ request が non-stream または直接接続では成功し、proxy、CDN、SDK wrapper、UI consumer 経由だけ失敗します。
- 設定を変更する前に、ステータスまたは例外、レスポンス本文、request ID、UTC 時刻、クライアント版、最終ホストを保存します。
- 最小リクエストと失敗するワークフローを比較し、全体障害、モデル固有、機能固有のどれかを切り分けます。
- 認証情報、完全なプロンプト、顧客データ、非公開ファイルをスクリーンショットやサポート資料に含めません。
主な原因と責任境界
エラーは一つのレイヤーから得た証拠であり、下流全体の故障を証明するものではありません。まず次の可能性を順に検証します。
- proxy が SSE を buffer・compress し、idle または response timeout で終了する。
- event framing が変更され、空行不足または誤った protocol 前提で parse される。
- client が iteration を止め、cancel・exception・listener cleanup を誤る。
- upstream model または network が terminal event 前に stream を閉じる。
レイヤー別に最小診断を行う
可変要素が最も少ないリクエストから開始します。アカウント、API ホスト、対象モデルは維持し、任意機能だけを外します。
一度に一項目だけ変更し、元のステータス、ヘッダー、本文、所要時間を残します。これによりクライアントのシリアライズとゲートウェイ・上流の挙動を分離できます。
- 01境界を確定同じ model・input を non-stream で実行し生成基準を作ります。
- 02基準を作成raw Content-Type、event boundary、data frame、terminal signal を確認します。
- 03一項目を比較direct と proxy 経路で buffering、compression、idle timeout を比較します。
- 04決定的な証拠を記録consumer の iteration、cancel、exception、cleanup を追跡します。
curl -N -sS --max-time 120 'https://<your-api-host>/v1/chat/completions' -H "Authorization: Bearer ${API_KEY:?set API_KEY first}" -H 'Content-Type: application/json' --data '{"model":"<YOUR_MODEL_ID>","stream":true,"messages":[{"role":"user","content":"reply with three short words"}]}'
確認した根本原因に修正を適用する
証拠で確定したレイヤーだけを最小限変更します。決定的な設定エラーを広範な再試行や検証無効化で隠さないでください。
- 01障害レイヤーを修正適切な idle budget で SSE を逐次転送するよう proxy を設定します。
- 02必要な動作を復元別 API を混ぜず、選択 API が出す正確な event format を parse します。
- 03一時回避策を除去cancel、partial output、exception、listener cleanup を明示的に処理します。
started = false
completed = false
for event in stream:
started = true
validate_and_append(event)
if event_is_terminal(event): completed = true
if not completed:
mark_result_incomplete()
do_not_execute_follow_up_actions()一度の成功ではなく修正結果を検証する
最小確認が成功したら元の経路を再実行し、通常のストリーミング、同時実行数、タイムアウト条件でも安定することを確認します。
- incremental event が protocol 順序で届く。
- 正常 response に識別可能な terminal event・finish reason がある。
- cancel で upstream work、socket、listener が解放される。
- 中断出力が partial と明示され完全結果として保存されない。
セキュリティ境界とエスカレーション資料
認証、通信、権限、検証を弱めず、かつ機密情報を公開しない範囲で、再現とエスカレーションに必要な証拠を収集します。
- stream の完全な prompt・completion を既定で log しない。
- cancel 後に privileged tool を動作させ続けない。
- partial text にも moderation・validation を適用する。
- event type、sequence、elapsed time、proxy path、request ID を機密除去して共有する。
公式情報と検証範囲
本ガイドはプロトコル仕様とクライアント公式文書を根拠にしています。エラー文、再試行ヘッダー、設定項目はサービスやバージョンで変わるため、参照元を確認し、ログとリクエスト例を秘匿してから共有してください。
技術検証方法を見る