From 1699b1b36a323b69564e0ea3c9bf6b736a5fc5cc Mon Sep 17 00:00:00 2001 From: bolbol Date: Mon, 14 Sep 2026 17:22:06 +0000 Subject: [PATCH] runbook: incident faux positif n8n veille-versions-stack (14/09/2026) - cause racine, fix, piege cache n8n --- common/veille-versions-stack.md | 40 +++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/common/veille-versions-stack.md b/common/veille-versions-stack.md index 17e88ee..d464279 100644 --- a/common/veille-versions-stack.md +++ b/common/veille-versions-stack.md @@ -120,3 +120,43 @@ graph TD ```bash docker exec n8n ssh -p 22223 -i /tmp/id_vps_n8n -o BatchMode=yes n8n-versions-ro@tailscale-nyora-bridge "all" ``` + +--- + +## 5. Incident du 14/09/2026 — Faux positif n8n & correctif appliqué + +### Symptôme +Le 14/09/2026, Nabil a remarqué que la ligne `n8n` de la table `infra_versions` affichait `statut = À jour` alors que le conteneur (installé en `2.36.5`) accusait en réalité un retard réel vers la version stable `2.38.7` (release GitHub "Latest" du 11/09/2026), avec une beta `2.39.5` également disponible. + +### Cause racine +Le nœud `Préparer Éléments & Mapping` interroge Docker Hub avec `page_size=25&ordering=last_updated`. Le nœud `Analyser Écarts & Versions` retenait ensuite simplement le **premier** tag de la liste filtrée (`candidateTags[0]`), en supposant implicitement que l'ordre renvoyé par l'API reflète la récence sémantique des versions. + +Cette hypothèse s'est révélée fausse pour `n8nio/n8n` : le projet a démarré une cadence de publication très dense de tags `v3-rc-*` et `v3-nightly-*` (plusieurs par jour, en préparation de la version 3.0 qui abandonne l'installation npm). Ces tags noient les 25 premières places de `ordering=last_updated` sans jamais correspondre au filtre strict `^[v]?[0-9]+\.[0-9]+\.[0-9]+$`. Résultat : `candidateTags` finissait vide, et le code retombait silencieusement sur l'ancienne valeur stockée (`origItem.current_disponible`) — d'où le faux "à jour" qui se perpétuait semaine après semaine sans jamais être corrigé automatiquement. + +Vérifié en direct sur l'API Docker Hub le 14/09/2026 : le tag `2.39.5` se trouvait en position **27** sur `ordering=last_updated`, hors de portée de `page_size=25`. + +### Correctif appliqué par Claude +Deux modifications dans le workflow `veille-versions-stack` (ID `zUWN5K4Q1A2JKFIS`) : +1. `page_size` porté de `25` à `100` dans `Préparer Éléments & Mapping`. +2. Sélection du tag remplacée dans `Analyser Écarts & Versions` : au lieu de `candidateTags[0]`, tri explicite des candidats par comparaison semver (`major.minor.patch` parsés en entiers) et sélection du maximum — robuste indépendamment de l'ordre renvoyé par l'API. + +Sauvegarde de la définition du workflow conservée avant modification (nœuds JSON complets) avant tout changement. + +### Piège opérationnel découvert : édition directe en base ne suffit pas +L'édition a été appliquée par `UPDATE workflow_entity SET nodes = ...` directement en Postgres (accès `docker exec n8n-DB psql`), sans passer par l'API n8n (aucune clé API n8n en clair disponible dans les secrets consultés). **Un test du workflow immédiatement après l'UPDATE a continué à produire l'ancien résultat (faux "à jour")**, alors même qu'une relecture de la ligne en base confirmait bien le nouveau code JSON. Cause : n8n garde en mémoire la définition des workflows actifs et ne la recharge pas automatiquement suite à une modification faite hors de son propre mécanisme de sauvegarde/API. + +**Correctif de contournement** : redémarrage du conteneur `n8n` (`docker restart n8n`) pour forcer le rechargement de tous les workflows actifs depuis la base. Confirmé efficace après coup. + +**Règle à retenir pour toute future édition directe en base d'un workflow n8n actif (par n'importe quel agent)** : une modification SQL de `workflow_entity.nodes` sur un workflow actif nécessite un `docker restart n8n` pour être réellement prise en compte à l'exécution — la relecture de la ligne en base ne suffit pas à garantir que le moteur en mémoire est à jour. + +### Limite résiduelle connue (non corrigée) +Le fix élève la fenêtre de recherche de 25 à 100 tags, ce qui règle le cas du 14/09/2026, mais reste théoriquement contournable si la cadence de tags `nightly`/`rc` de n8n s'intensifie encore avant la sortie de la 3.0 (dépassement de 100 tags "bruit" entre deux vraies releases). Aucune pagination multi-pages n'a été implémentée — jugé disproportionné pour un job hebdomadaire, à revisiter si le faux "à jour" réapparaît. + +### Correction manuelle ponctuelle de la table Baserow +En parallèle du correctif workflow, la ligne `n8n` (id `3`) de `infra_versions` a été corrigée manuellement le 14/09/2026 : `derniere_version_disponible = 2.39.5`, `statut = Retard mineur`, `ecart` précisant la distinction stable (`2.38.7`, cible réelle de mise à jour) vs beta (`2.39.5`, ne jamais cibler la beta en production). + +### Dérive documentaire notée au passage (non corrigée) +La ligne `bifrost` (id `4`) de la même table reste étiquetée `emplacement = NAS` alors que Bifrost tourne réellement sur le VPS depuis le 04/09/2026 (voir [[bifrost-routing]] / `migration-vps-bifrost-stub-forwarder-20260904.md`). Correction à faire séparément, hors périmète de cet incident. + +### Ticket de suite +`infra-2026-09-051` (Baserow, assigné à Gemini) : mise à jour effective NAS (n8n vers 2.38.7 stable + gitea/portainer/vaultwarden/crowdsec), avec vérification à froid de version et backup dédié obligatoires avant toute exécution.