Files
nas-runbooks/common/veille-macbook-brain-watch-filtre-prerelease.md
T

3.1 KiB

MacBook Brain Watch — filtrage prerelease + consolidation (29/07/2026)

Contexte

Workflow n8n 9MkE8Fx3ZlY485Y5 ("INFRA | OpenHuman Watch", cron 4h) surveille les releases GitHub de deux projets candidats pour le futur stack local du MacBook (OpenHuman tinyhumansai/openhuman, Vellum vellum-ai/vellum-assistant). Un premier fix (25-27/07) avait remplacé la dédup lastSeenId unique par un historique d'IDs vus (array cappé à 30), pour stopper le renvoi en boucle causé par l'alternance stable/prerelease en tête du flux Atom Vellum.

Symptôme persistant après le premier fix

18 notifications Telegram+Email reçues en ~24h (29/07), toutes issues d'OpenHuman/Vellum. Le premier fix corrigeait bien la boucle de re-notification, mais pas la cause de fond : vellum-ai/vellum-assistant publie un tag -staging.N "cherry-pick" à chaque build interne avant la release finale (ex. v0.11.0-staging.1, .2, .3 puis v0.11.0), et chaque tag a un ID Atom unique → chacun est légitimement "nouveau" pour la dédup et génère sa propre notif Telegram + email.

Cause racine

Confusion entre deux problèmes distincts : "ne pas re-notifier un ID déjà vu" (résolu le 25-27/07) vs "ne pas notifier chaque changement de nom de build/tag interne" (jamais traité). Vérifié en direct sur les flux Atom réels : sur les 10 dernières entrées Vellum, 7 sont des -staging.N, seules 3 sont des releases stables.

Fix appliqué

Node "🔍 Fetch Releases GitHub & Vellum" modifié :

  • Ajout d'un filtre regex /-(staging|rc|beta|alpha|dev|nightly|pre|preview|cherry)/i sur id/title : les tags de build interne sont marqués vus (pour ne jamais les retraiter) mais exclus de la notification.
  • Consolidation : au lieu d'un Telegram + un email par entrée détectée, une seule notification Telegram et un seul email par exécution, regroupant toutes les releases stables trouvées (toutes projets confondus).
  • Validation faite en conditions réelles : code testé dans le container n8n avec les vrais flux Atom (via node - + fichiers copiés par docker cp), confirmant que le filtre élimine bien 7/10 entrées Vellum bruit et conserve les vraies releases (OpenHuman conserve son rythme de sorties stables, qui reste un signal légitime de maturité du projet).
  • Déploiement : UPDATE workflow_entity.nodes via psql (payload passé en stdin, jamais en argument de ligne de commande, pour éviter les limites de taille/quoting) puis docker restart n8n (obligatoire : n8n ne recharge pas les nodes actifs à chaud). Vérifié post-restart : n8n healthy, workflow toujours actif.

Non traité (dette déjà connue, inchangée)

Token Telegram en clair dans le node Code — nécessite un rebranchement sur credential ND_Telegram, changement plus large à faire séparément avec validation UI.

Piège à retenir

Sur un flux Atom GitHub de projet à cadence CI élevée, la dédup par ID seule ne suffit jamais à filtrer le bruit : elle empêche la répétition mais pas le volume. Il faut un filtre de contenu (naming convention prerelease/staging/rc) en plus de la dédup, et idéalement consolider en un seul message par cycle plutôt qu'un message par item.