Streaming और SSE disconnect: duplicates के बिना recovery

सामान्य completion या वास्तविक disconnect

Server-Sent Events लंबे HTTP connection पर events की sequence भेजते हैं। Client इनमें से किसी outcome तक पढ़ता है:

created -> receiving -> completed
                   \-> failed
                   \-> disconnected

completed protocol का terminal event है। failed stream के भीतर आई error है। disconnected मतलब transport confirmed final के बिना बंद हुआ और diagnosis चाहिए।

OpenAI Responses API में response.created, output fragments और response.completed जैसे events तथा failed/incomplete states हैं। Anthropic Messages में message_start, content-block events, message_delta और message_stop हैं। Names को एक parser में mix न करें।

Controlled stream test के लिए BetterToken account और API Key बनाएँ, API reference खोलें और tool calls के बिना short stream से शुरू करें। Dashboard में time, model और status मिलाएँ; terminal event और partial output जाँचने के बाद ही bounded retry जोड़ें।

Disconnect पर कौन-से data सहेजें

Minimum log client और server problem अलग करने में मदद करता है:

{
  "started_at": "2026-08-03T12:00:00Z",
  "protocol": "openai-responses",
  "request_id": "req_placeholder",
  "http_status": 200,
  "last_event_type": "response.output_text.delta",
  "events_received": 42,
  "bytes_received": 8192,
  "terminal_event_received": false,
  "client_error": "socket closed"
}

API Key, full prompt, tool arguments या sensitive response न रखें। Partial text केवल application policy अनुमति दे तो store करें। Production में operation hash, event count और last safe sequence marker अधिक उपयोगी हैं। Request ID header या event से आ सकता है; उसे stream समाप्त होने की प्रतीक्षा किए बिना सहेजें।

Network से पहले parser जाँचें

Client को multiple data: lines, empty separators, network chunk boundary पर UTF-8 fragments, unknown event type, successful HTTP के बाद error event, final text delta के बिना terminal event और chunks में बँटे tool arguments handle करने चाहिए। TCP chunk SSE event नहीं है: पहले full SSE frame बनाएँ, फिर JSON parse करें।

state = receiving
for event in parse_sse(response_body):
    log_safe_metadata(event)
    apply_event_to_partial_result(event)

    if is_terminal_success(event):
        state = completed
        break
    if is_terminal_failure(event):
        state = failed
        break

if connection_closed and state == receiving:
    state = disconnected

is_terminal_success और is_terminal_failure Responses, Chat Completions और Messages के लिए अलग functions हों।

हर layer का timeout जाँचें

Long connection SDK/HTTP client timeout, application idle/read timeout, reverse proxy, load balancer/ingress, corporate proxy, home/mobile network और server-side generation limit से गुजरती है। Overall request timeout और idle timeout अलग हैं। Model regular events भेज रही हो तो short idle timeout नहीं लगना चाहिए; acceptable pauses हों तो value expected load के अनुरूप रखें।

Buffering proxy भी जाँचें। वह SSE chunks जमा करे तो user को देर से बड़ा block या timeout मिल सकता है। First-event time और event intervals को local, reverse proxy और production में अलग-अलग measure करें।

Partial output: दिखाएँ, सहेजें या हटाएँ

Partial text UI में उपयोगी है, पर उसका status स्पष्ट होना चाहिए; truncated answer को complete न दिखाएँ। State model रखें: streaming (text बदल रहा है), complete (terminal success मिला), partial (कुछ events के बाद connection टूटा), failed (protocol error), cancelled (user/app ने रोका)।

partial text को new retry से अलग रखें। दो generations को automatically जोड़ना जोखिमपूर्ण है: model पुराना भाग दोहरा सकती, wording बदल सकती या tools अलग क्रम में बुला सकती है।

Request कब repeat कर सकते हैं

बाहरी action के बिना text

Short text request को finite attempts के साथ repeat किया जा सकता है। App पुराने result को partial रखे और नया अलग generation के रूप में दिखाए, अथवा explicit confirmation के बाद replace करे।

Tool calls और transactions

Retry से पहले जाँचें tool पहले चल चुका है या नहीं। Command भेजने के बाद stream टूटे तो दूसरा request issue, email या payment फिर बना सकता है। Tool level idempotency key, अपना operation ID और executed-actions log लें।

लंबी agent task

“Last token से continue” automatic protocol feature कम ही होता है। Confirmed messages, tool results और last completed step जैसे saved application state से task rebuild करें। Raw fragments को consistent agent state न कहें।

Backoff के साथ bounded retry

Retry policy में attempts finite हों:

attempts = 0
while attempts < MAX_ATTEMPTS:
    result = run_request(operation_id)
    if result.completed:
        return result
    if not result.retryable:
        raise result.error
    wait(base_delay * 2**attempts + random_jitter)
    attempts += 1

Retryable decision protocol error, HTTP status, terminal event और side effects से आता है। 401, invalid Model ID और invalid JSON pause से ठीक नहीं होते। 429, temporary 5xx या transport failure कभी retry योग्य हैं, लेकिन provider headers और limits के साथ।

न्यूनतम test

1. Tools के बिना short streaming request भेजें।
2. सभी event types लिखें और terminal event तक प्रतीक्षा करें।
3. कुछ events के बाद client को जानबूझकर interrupt करें।
4. Result को partial marked पाएं।
5. एक bounded retry जाँचें।
6. Production proxy के पीछे test दोहराएँ।
7. दोनों requests को Dashboard में time, model और status से मिलाएँ।

Exact events OpenAI streaming Responses और Anthropic Messages streaming से लें।

FAQ

क्या stream को last token से continue कर सकते हैं?

कोई universal mechanism नहीं। Partial result और application state सहेजें, फिर concrete API की capabilities के अनुसार चलें। नया request text दोहरा या बदल सकता है।

HTTP status 200 के बाद stream error क्यों हुई?

Headers full generation से पहले आते हैं। बाद में protocol event या transport disconnect error हो सकता है; इसलिए केवल status पर्याप्त नहीं।

क्या हर disconnect पर retry जरूरी है?

नहीं। पहले terminal event, error, request ID और side effects जाँचें। Tool call का retry idempotency मांगता है।

Local सब चलता है, तो कारण कहाँ खोजें?

Reverse proxy, load balancer, idle timeout, buffering और corporate network जाँचें। हर layer से पहले/बाद event intervals compare करें।

BetterToken में क्या मिलाएँ?

Dashboard में time, model, status और usage मिलाएँ। Request parameters के लिए API reference देखें; support को full API Key या sensitive prompt न भेजें।