« Streaming interrupted. Waiting for the complete message » — signification et solution

Les trois gestes des 90 secondes

Régénérez la réponse, rechargez la page (si vous êtes sur mobile, quittez complètement l’application puis rouvrez-la), puis déconnectez-vous et reconnectez-vous. Une connexion interrompue ponctuellement est rétablie par l’un de ces trois gestes, et la plupart des cas sont ponctuels. Si la réponse s’arrête toujours exactement au même endroit, cela indique que la cause est l’une des causes précises ci-dessous plutôt qu’une coupure passagère.

Déterminer si le problème vient réellement de chez vous

C’est l’étape que les autres listes de solutions oublient, et celle qui fait gagner le plus de temps. Ouvrez status.openai.com. Si un incident est signalé, aucun réglage sur votre machine ne changera quoi que ce soit et la seule solution est d’attendre. Si rien n’est signalé, la cause est locale et l’étape suivante permettra de l’isoler. Faire cela avant de modifier les réglages vous évite de passer vingt minutes à vider les caches pour une panne.

Isoler la cause locale de l’extérieur vers l’intérieur

Parcourez les couches dans cet ordre, car chacune écarte tout ce qui se trouve au-dessus : (1) désactiver le VPN et le proxy ; (2) ouvrir une fenêtre privée, ce qui supprime les extensions et le cache en une seule opération ; (3) essayer un autre navigateur ou appareil ; (4) changer de réseau. La couche à partir de laquelle le problème disparaît est la cause. Si l’erreur apparaît uniquement dans les fils longs, aucune des quatre n’est en cause — transférez les points clés dans une nouvelle discussion.

Pour les développeurs : la même interruption dans l’API

Lors d’un appel à l’API avec stream: true, cette défaillance se manifeste par une connexion Server-Sent Events qui se termine sans finish_reason. L’état HTTP est 200 — tout fonctionnait lorsque les en-têtes ont été envoyés — ; les seules vérifications du code d’état ne la détecteront donc pas. Sous charge, vous verrez également 429 et 529 overloaded_error. Trois mesures la rendent supportable : (1) traiter un flux terminé sans finish_reason comme réessayable, et non comme une réponse terminée ; (2) relancer les requêtes 429, 500 et 529 avec un backoff exponentiel et du jitter ; (3) si vous êtes derrière un proxy, vérifier son délai d’inactivité et désactiver la mise en tampon des réponses — un proxy qui met en tampon transforme un flux fonctionnel en long blocage. Reproduisez d’abord le problème sans proxy :

# Stream directly, no proxy in the path, and watch where it stops.
curl -N https://api.kunavo.com/v1/chat/completions \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","stream":true,
       "max_tokens":300,
       "messages":[{"role":"user","content":"count slowly from 1 to 20"}]}'

« streaming interrupted, waiting for the complete message » est-il de ma faute ?

Presque jamais. Le message signifie que la connexion qui transportait la réponse a été interrompue avant la fin. Ce que vous avez saisi n’en est pas la cause. Les causes sont une charge élevée du côté d’OpenAI, un réseau instable, une extension de navigateur ou une session obsolète, ou encore un fil devenu suffisamment long pour faire expirer les réponses.

Que faire si la régénération ne résout pas le problème ?

Consultez d’abord status.openai.com — pendant un incident, rien de local ne peut aider. S’il n’y a aucun incident, ouvrez une fenêtre privée sur un autre réseau : ce test unique supprime simultanément les extensions, le cache et votre liaison habituelle. Si cela fonctionne, réintroduisez chaque élément jusqu’à ce que le problème réapparaisse. Si l’échec survient partout et uniquement dans une longue conversation, transférez les points clés dans une nouvelle discussion.

Cela arrive-t-il avec d’autres chats d’IA ?

La formulation est propre à ChatGPT, mais tout assistant qui diffuse des réponses en streaming peut être interrompu de la même manière. Claude affiche un message indiquant qu’il n’a pas pu terminer la réponse ; lors d’un appel direct à l’API, cela apparaît comme un flux Server-Sent Events qui se termine sans finish_reason, ou comme une erreur 529 overloaded_error sous charge.

Pourquoi l’erreur apparaît-elle plus souvent dans les longues conversations ?

Chaque tour renvoie l’intégralité du fil ; une longue conversation implique donc une génération plus longue maintenue sur une seule connexion. Plus cette connexion reste ouverte, plus les risques qu’un délai d’expiration de proxy, un changement de réseau ou un incident en amont l’interrompe sont nombreux. Commencer une nouvelle discussion avec un résumé de l’essentiel améliore généralement davantage la situation que n’importe quel réglage du navigateur.

Suis-je facturé lorsqu’un flux est interrompu ?

Avec les abonnements ChatGPT, il n’y a pas de facturation par message ; la seule perte concerne donc le temps. Dans l’API, la facturation dépend des jetons effectivement produits par le fournisseur ; un flux qui meurt prématurément coûte donc moins cher qu’un flux complet — et sur Kunavo, une requête qui échoue complètement n’est pas facturée.