Accueil → Aide

socket hang up au milieu d'une réponse en streaming

Ce que vous voyez

• Error: socket hang up
• ECONNRESET / read ECONNRESET
• aiohttp.ClientPayloadError: Response payload is not completed
• The text stops mid-sentence with no finish_reason

Pourquoi cela arrive

Les longs flux traversent plus d'infrastructure que les requêtes courtes : votre réseau, un éventuel proxy, la périphérie du fournisseur et l'hôte du modèle. Un délai d'inactivité n'importe où dans cette chaîne ferme la connexion, et le client le signale comme une réinitialisation plutôt que comme une erreur HTTP, car la réponse HTTP avait déjà commencé par un 200.

Les réseaux mobiles et la mise en veille d'un portable produisent la même signature. Tout comme un répartiteur de charge dont le délai d'inactivité est plus court que le temps de réflexion du modèle, ce qui explique que les modèles de raisonnement y soient plus exposés que les modèles rapides.

Un flux qui se termine par un finish_reason correct puis produit une erreur, c'est autre chose : la réponse est complète et seule la fermeture a échoué. Celle-là peut être utilisée sans risque.

Comment le corriger

1. Utilisez finish_reason comme signal de finNe considérez pas « le flux s'est terminé » comme un succès. Marquez une réponse comme complète seulement si un finish_reason est arrivé ; sinon, relancez ou présentez-la comme tronquée.
2. Relancez la requête, pas le fluxIl n'existe pas de point de reprise dans une réponse en streaming. Relancez depuis le début, idéalement avec un max_tokens plus bas pour que la tentative suivante se termine plus vite.
3. Augmentez ensemble les délais du client et du proxyAugmenter seulement le délai du client ne sert à rien si un proxy situé devant ferme plus tôt. Les deux doivent dépasser la réponse la plus lente que vous attendez.

Voir aussi

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.