VESICA
IQSYS_IQ_5Brouillon

SYS_IQ_5 — Traiter un échec d'appel LLM & configurer l'Error Workflow

Instruction· Direction des Systèmes d'Information (DSI) — Système & Infrastructure IA· émetteur VESICA SYS_PRO_5

SYS_IQ_5 — Traiter un échec d'appel LLM & configurer l'Error Workflow

Mode opératoire + embryon de catalogue : règles D1/D2 et anti-récursion avec source_ref. [CORPUS]

Objet (la tâche)

(1) Garantir qu'un échec d'appel LLM est tracé, notifié et rendu proprement par agent_call ; (2) configurer correctement l'Error Workflow error_handler sur les workflows critiques, sans créer de récursion. [CORPUS]

Prérequis / matériel / sécurité

  • notify_system opérationnel (event llm_error + workflow_error déclarés dans routage_notifs.json). [CORPUS]
  • Credential Postgres append-only valide (pour log_llm_call). [CORPUS]
  • Connaître la distinction échec (erreur technique) vs production insuffisante (relance/tentative, UC-A11) — ne pas confondre. [CORPUS]
  • Pas de donnée sensible côté SYS. [STANDARD]

Étapes d'exécution

Côté agent_call (déjà câblé — pour maintenance/extension)

  1. HTTP en onError:continueErrorOutput (sortie 1 sur non-2xx). [CORPUS]
  2. Parse response : garde D2 (throw si resp.error || !choices.length, onError:continueErrorOutput). [CORPUS]
  3. Les 2 sources convergent sur Build error log payload (success=false, tokens/coût null). [CORPUS]
  4. Call log_llm_call (erreur) + Call notify_system (llm_error) en onError:continueRegularOutput. [CORPUS]
  5. Error output terminal {success:false} — pas de throw. [CORPUS]

Côté Error Workflow (configuration)

  1. Activer error_handler (u8niaUdf9cAX1Kjr) comme Error Workflow dans les settings des workflows critiques. [CORPUS]
  2. Ne jamais mettre error_handler comme Error Workflow sur notify_system/notify_business/mattermost_post_message (anti-récursion). [CORPUS]
  3. Tester en mode integrated (pas run manuel éditeur). [CORPUS]

Règles, critères et seuils (embryon de catalogue — résilience)

  • E1 — D1 : sur échec LLM, agent_call rend {success:false} sans throw → error_handler ne fire pas → une seule notif (llm_error). (source_ref: ADR-029 D5 ; 07 §B2.11) [CORPUS]
  • E2 — D2 : HTTP 200 + body.error ou choices vide = échec (soft-error) → même branche. (source_ref: 07 §B2.11) [CORPUS]
  • E3 — Sortie d'échec = même contrat de surface que le succès (success, content:null, usage:null, error). L'appelant teste success. (source_ref: 07 §B2.11) [CORPUS]
  • E4 — Tous les appels d'observabilité (log/notif) en onError:continueRegularOutput : une trace/notif KO ne masque pas l'erreur LLM. (source_ref: ADR-029 ; 07 §B2.11) [CORPUS]
  • E5 — Anti-récursion : chaîne de livraison de notif sans error_handler (Coupe 1) ; error_handler avale sa propre notif (Coupe 2). (source_ref: ADR-034 ; P-6g-1) [CORPUS]
  • E6 — Error Workflow ne fire qu'en prod/integrated, jamais en run manuel éditeur. (source_ref: P-6g-2) [CORPUS]
  • E7 — Échec ≠ production insuffisante : une réponse faible mais valide → relance (tentative, modèle supérieur), pas la branche d'échec. (source_ref: M1 ; UC-A11) [CORPUS]
  • E8 — latency_ms à l'échec = Date.now() − t0 (inclut le temps avant erreur). (source_ref: 07 §B2.11) [CORPUS]

Points de contrôle / cas particuliers

  • Double source mutuellement exclusive : sur 1 item, HTTP-erreur et soft-error D2 ne peuvent pas coexister → Build error log payload reçoit exactement 1 item (jamais de double log/notif). [CORPUS]
  • Import-over : un ré-import peut suffixer un nœud …1 (P-6h-1) → vérifier les binds. [CORPUS]
  • pinData intermédiaire survit aux runs manuels et fausse les deux sorties (P-6h-2) → dé-piner avant test réel. [CORPUS]
  • Retry transitoire : non câblé v0 ; un 429/503 est aujourd'hui un échec sec (pas de backoff). [STANDARD] [À CONFIRMER]

Sortie / enregistrement produit

  • Ligne telemetrie.appels_llm success=false (cf. SYS_FQ_2) + notif llm_error/workflow_error dans system-errors. [CORPUS]

Agent responsable

agent_call (branche d'échec) ; error_handler (Error Workflow). [CORPUS]