mirror of
https://github.com/R0m1k3/Loki.git
synced 2026-10-22 06:28:11 +02:00
Le flux de reponse coupe ne s'arrete plus en silence (issue #19)
sc.Scan() rend false aussi bien a la fin normale d'un flux qu'a la premiere erreur de lecture, et sc.Err() n'etait JAMAIS consulte. Une connexion reinitialisee en plein milieu, ou une ligne plus longue que le tampon, etait donc indiscernable d'une fin propre : le tour s'arretait sans un mot pendant que le journal de llama-server affichait un « stop processing » parfaitement normal. C'est le symptome rapporte — l'agent enchaine quelques commandes puis rend la main sans avoir termine ni commente. Pire : des appels d'outils accumules a moitie auraient ete EXECUTES avec des arguments tronques. On abandonne desormais le tour en nommant la cause, le texte deja recu reste affiche, et un stop volontaire reste silencieux. Trois tests couvrent les trois cas ; celui du flux coupe echoue bien sur l'ancien code. Tampon du scanner porte de 1 a 8 Mio au passage : la cause la plus probable d'une ligne trop longue est un appel d'outil demesure, et jusqu'ici il partait dans le meme silence. Sans rapport, trouve en faisant tourner la suite : renameAside tirait son nom du seul UnixNano, dont la granularite Windows peut rendre deux fois la meme valeur — deux ecartements se disputaient alors le meme nom, le second ecrasant le binaire mis de cote par le premier. Un compteur atomique les departage.
This commit is contained in:
1 parent
4a66b27227
commit
42cdb2cda3
3 files changed
+178
-3
No files matched your search
@@ -517,6 +517,17 @@ func errEngineReset() error {
|
||||
return fmt.Errorf("⚠️ Connexion au moteur (llama-server, port %d) interrompue — il a peut-être redémarré. Réessaie.", LLMPort())
|
||||
}
|
||||
|
||||
// streamCutError explique un flux de complétion coupé en cours de route. Cas à
|
||||
// part de friendlyLLMError : ici la requête avait ABOUTI (200 reçu, tokens déjà
|
||||
// reçus), c'est la lecture qui a lâché. Le dire autrement qu'un « le moteur ne
|
||||
// répond pas » évite d'envoyer l'utilisateur vérifier un moteur qui va bien.
|
||||
func streamCutError(err error) error {
|
||||
if errors.Is(err, bufio.ErrTooLong) {
|
||||
return fmt.Errorf("⚠️ Réponse du moteur illisible : une ligne du flux dépasse la taille maximale (%d Mio). C'est presque toujours un appel d'outil démesuré (écriture d'un très gros fichier). Le tour est abandonné pour ne pas exécuter un appel tronqué.", 8)
|
||||
}
|
||||
return fmt.Errorf("⚠️ Le flux de réponse du moteur (llama-server, port %d) a été coupé en cours de route : %v. La réponse est incomplète et le tour est abandonné — réessaie.", LLMPort(), err)
|
||||
}
|
||||
|
||||
// isNetTimeout : une erreur réseau qui se déclare elle-même comme un délai
|
||||
// dépassé (net.Error.Timeout), quel que soit son libellé.
|
||||
func isNetTimeout(err error) bool {
|
||||
@@ -650,9 +661,12 @@ func runChat(ctx context.Context, messages []Message, temperature float64, caps
|
||||
sawReasoningField := false
|
||||
thinkOpen := reasoningOn
|
||||
var thinkTail strings.Builder
|
||||
// scanner with a big buffer — some chunks include large arguments JSON
|
||||
// Scanner à gros tampon : un chunk peut porter un gros JSON d'arguments
|
||||
// (écriture de fichier). 8 Mio et non 1 : au-delà du tampon, le scanner
|
||||
// s'arrête sur « token too long » AU MILIEU du flux, et jusqu'à la 0.8.4
|
||||
// personne ne le voyait (voir sc.Err() plus bas).
|
||||
sc := bufio.NewScanner(resp.Body)
|
||||
sc.Buffer(make([]byte, 0, 64*1024), 1<<20)
|
||||
sc.Buffer(make([]byte, 0, 64*1024), 8<<20)
|
||||
aborted := false
|
||||
for sc.Scan() {
|
||||
line := strings.TrimSpace(sc.Text())
|
||||
@@ -832,10 +846,25 @@ func runChat(ctx context.Context, messages []Message, temperature float64, caps
|
||||
if !aborted && thinkOpen && thinkTail.Len() > 0 {
|
||||
cb(StreamEvent{Content: strings.TrimLeft(thinkTail.String(), "\r\n")})
|
||||
}
|
||||
// ⚠️ Le flux a-t-il fini, ou CASSÉ ? sc.Scan() renvoie false dans les deux
|
||||
// cas, et l'erreur n'était jamais consultée : une lecture coupée en plein
|
||||
// milieu (connexion réinitialisée, ligne plus longue que le tampon) était
|
||||
// donc indiscernable d'une fin normale. Vécu par l'utilisateur : l'agent
|
||||
// enchaîne quelques commandes puis « s'arrête et rend la main sans avoir
|
||||
// terminé, ni même commenté », pendant que le journal de llama-server
|
||||
// affiche un « stop processing » parfaitement normal (issue #19). Pire,
|
||||
// des appels d'outils accumulés à moitié auraient été EXÉCUTÉS avec des
|
||||
// arguments tronqués. On refuse donc le tour, en le disant.
|
||||
scanErr := sc.Err()
|
||||
resp.Body.Close()
|
||||
if aborted {
|
||||
return extra, nil
|
||||
}
|
||||
if scanErr != nil && ctx.Err() == nil {
|
||||
err := streamCutError(scanErr)
|
||||
cb(StreamEvent{Err: err})
|
||||
return extra, err
|
||||
}
|
||||
|
||||
// Treat any accumulated tool calls as a tool turn even if the backend set
|
||||
// finish_reason to "stop" instead of "tool_calls" (some llama.cpp builds
|
||||
|
||||
Reference in new issue
Block a user