VESICA
PQSYS_PQ_5Brouillon

SYS_PQ_5 — Procédure de gestion des erreurs et résilience

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

SYS_PQ_5 — Procédure de gestion des erreurs et résilience

Procédure légère. Détails dans error_handler, la branche d'échec d'agent_call, et les ADR. [CORPUS]

Objet

Décrire comment le système capture, signale et isole les erreurs (exceptions de workflow et échecs LLM), sans cascade ni blocage. [CORPUS]

Domaine d'application

Tous les workflows critiques (Error Workflow error_handler configuré) + spécifiquement agent_call (branche d'échec LLM). Exclusion : les chaînes de livraison de notif ne portent pas error_handler (anti-récursion ADR-034). [CORPUS]

Références

  • Workflows : 07 §B2.8 (error_handler), §B2.11 (branche d'échec). [CORPUS]
  • ADR-034 — anti-récursion (Coupe 1 + Coupe 2). [CORPUS]
  • ADR-029 D5 — sur échec, agent_call trace puis rend {success:false} sans throw ; la notif llm_error dédiée remplace l'exception générique. [CORPUS]
  • P-6g-1 (storm récursif), P-6g-2 (Error Workflow ≠ run manuel), P-6h-1/2 (import-over, pinData). [CORPUS]
  • Pas de norme externe applicable. [STANDARD]

Définitions

  • Error Workflow : workflow déclenché par l'Error Trigger natif n8n quand un workflow référent lève une exception non gérée (settings). [CORPUS]
  • Fire-and-forget : un appel d'observabilité (log/notif) en onError:continueRegularOutput — un échec ne masque ni ne casse le flux. [CORPUS]
  • Soft-error D2 : HTTP 200 + corps invalide → traité comme un échec. [CORPUS]
  • D1 (retour propre) : agent_call rend {success:false} sans throw → error_handler ne fire pas. [CORPUS]

Responsabilités (RACI)

ActivitéWorkflow critiqueerror_handleragent_call (branche échec)notify_systemGérant
Lever/propager l'exceptionRC———
Capturer + router workflow_errorAR—CI
Gérer l'échec LLM (D1/D2)——RCI
Garantir le non-blocageCRRC—
Configurer Error Workflow (settings)————R/A
Lire system-errors + agir————R

Déroulement (qui/quoi/quand/où)

A) Exception non gérée

  1. Un workflow critique lève une exception (prod/integrated). [CORPUS]
  2. L'Error Trigger déclenche error_handler. [CORPUS]
  3. error_handler récupère le contexte → notify_system event workflow_error → system-errors. [CORPUS]
  4. Son nœud notif est en onError:continueRegularOutput (Coupe 2) → pas de relance. [CORPUS]

B) Échec LLM (agent_call, 6h)

  1. HTTP non-2xx (sortie erreur) ou soft-error D2 (garde throw dans Parse response, onError:continueErrorOutput) → convergence sur Build error log payload (1 item exactement). [CORPUS]
  2. success=false, tokens/coût null, latency=Date.now()−t0. [CORPUS]
  3. Call log_llm_call (erreur) [fire-and-forget] → ligne télémétrie success=false. [CORPUS]
  4. Prepare llm_error payload → Call notify_system (llm_error) [fire-and-forget] → system-errors. [CORPUS]
  5. Error output terminal {success:false, content:null, error} — ne rejoint jamais la sortie succès, pas de throw (D1). [CORPUS]

Enregistrements associés

  • Lignes telemetrie.appels_llm success=false (cf. SYS_FQ_2). [CORPUS]
  • Messages system-errors. [CORPUS]

Annexes

  • Test (6/6, 6h) : nominal 0 notif ; échec HTTP → success=false + 1 notif ; une seule notif ; soft-error D2 routée ; fire-and-forget prouvé (log_llm_call cassé → 0 ligne, notif+sortie OK) ; compteur f=4/t=4. [CORPUS]
  • Pour tester error_handler : provoquer l'erreur en mode integrated (Manual Trigger → Execute Workflow(cible) avec input fautif), jamais en run manuel éditeur (P-6g-2). [CORPUS]