File résiliente : une coupure d'infra ne tue plus la tâche

Correctifs de productionRemise en file en cas de coupure d'infra, ne pas marquer comme annulé au redémarrage, deux requêtes que PostgreSQL rejetait toujours, garde de classe pour les silent failures, et warmup de threads d'email sans réponse pré-écrite.

Pourquoi c'est une actualité produit

Les 15 spécialistes d'ADRI dépendent d'OllamaTasker + Node balancer + FastAPI. Si un worker redémarre à 3AM, le commercial ne devrait pas voir « vous avez annulé la tâche ». Il devrait voir une nouvelle tentative ou une remise en file — et le silent-failure-hunter ne devrait pas mentir sur la coupure.

• Les tâches longues (OSINT, code, vision) survivent aux blips
• La facturation et tools_used ne se clôturent qu'à la fin réelle du tour
• Les opérateurs voient la raison honnête de la coupure

Architecture de files d'attente sur votre on-prem

Ce qui échoue quand la file n'est pas résiliente

Dans une architecture multi-agents (Laravel tasker + balancer Node + API Python), un redémarrage de worker à 3:00 n'est pas « un bug rare » : c'est le quotidien. Si la tâche est marquée comme annulée ou disparaît, l'utilisateur perd confiance et la facturation se désynchronise (tour ouvert, tools facturés à moitié).

• Remise en file : l'unité de travail retourne dans la file avec le même id de session/workspace.
• Idempotence : les tools d'écriture ne dupliquent pas les effets si l'étape se répète.
• Clôture honnête : les tokens et tools_used sont consolidés à la fin réelle du tour.

Signaux opérationnels

Les opérateurs doivent voir pourquoi une nouvelle tentative a eu lieu (timeout LLM, OOM, deploy), pas une « erreur générique ». C'est ce qui permet de distinguer une défaillance de modèle d'une coupure d'infra.

Questions fréquentes

En relation : agents ADRI · architecture dans votre infra.

• Files d'attente
• Résilience
• OllamaTasker
• SRE