runbook: incident faux positif n8n veille-versions-stack (14/09/2026) - cause racine, fix, piege cache n8n

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.