2026 OpenClaw MeshMac en pratique : Webhook Asana pour diffusion multi-nœuds des builds et résumé d’échec renvoyé sur la tâche

Traitez le webhook comme de l’infrastructure, pas comme un favori par développeur. Vous voulez une cible POST stable sur le nom d’hôte de la passerelle, qui survive aux mises à jour Xcode, aux vidages de nœud et à l’élasticité des builders.

1. Étape 1. Dans l’application développeur Asana (ou l’intégration d’espace de travail) qui porte votre automatisation, créez un webhook dont la ressource est le projet, l’équipe ou le portefeuille concerné. Collez une URL du type https://passerelle.exemple/openclaw/v1/asana/webhook (chemin indicatif : dédiez-le et documentez-le).
2. Étape 2. Réalisez la poignée de main Asana : lors du premier POST, recopiez l’en-tête X-Hook-Secret dans les en-têtes de réponse sans le modifier, répondez 200 ou 204, puis enregistrez cette valeur comme clé de signature pour tous les contrôles X-Hook-Signature ultérieurs (vérifiez aussi le corps 201 si vous utilisez le flux REST de création).
3. Étape 3. Stockez ce secret avec des droits restrictifs (par exemple mode 0440 et utilisateur de service dédié), comme décrit dans le guide secrets et moindre privilège sur les nœuds MeshMac. Le secret ne doit jamais se trouver dans une image de builder — uniquement sur la passerelle.
4. Étape 4. Filtrez agressivement dans la configuration : ignorez les types d’événements bruyants en périphérie pour qu’OpenClaw ne mette en file que lorsqu’une tâche passe dans une section « à builder » ou qu’un champ personnalisé convenu change. Les événements ignorés doivent tout de même renvoyer 200 rapidement après authentification.

Exposez le point public derrière la même politique TLS et la même limite de taille de corps que pour les autres entrées SaaS ; dimensionnez la concurrence des livraisons webhook par rapport au budget CPU de la passerelle, afin qu’un pic d’activité Asana n’affame pas les callbacks CI.

Vérifier d’abord, analyser ensuite. L’en-tête X-Hook-Signature d’Asana est un HMAC-SHA256 hexadécimal des octets exacts postés. Un middleware qui parse le JSON avant, réindent le corps ou normalise l’Unicode produira des dérives de signature « impossibles » sous charge.

1. Étape 1. Lisez le corps brut dans un tampon sur le processus passerelle avant tout décodeur JSON.
2. Étape 2. Calculez HMAC_SHA256(secret_X_Hook_Secret_stocké, corps_brut), encodez en hexadécimal et comparez à X-Hook-Signature en temps constant (Asana signe le corps entier ; les battements de cœur peuvent être du JSON vide).
3. Étape 3. En cas d’écart, répondez 401 et journalisez une ligne réduite (identifiant de livraison, route, longueur en octets) — jamais le secret ni la charge complète.
4. Étape 4. Après vérification, analysez l’enveloppe, dédupliquez avec les identifiants de livraison Asana ou un hachage resource.gid + action + changed_at dans une courte fenêtre temporelle, puis mettez en file.

Ne renvoyez 200 qu’après une mise en file durable, pour que les relances Asana ne dupliquent pas les compilations. L’ordonnancement et la politique de retry rejoignent les étapes file de tâches et retry sur pools Mac partagés.

Le routage est le contrat entre « ce qu’Asana a dit » et « ce que tout nœud MeshMac a le droit d’exécuter ». Restez sobre : une table dans la configuration OpenClaw associe (resource_type, action) à une tâche normalisée que vos workers comprennent déjà.

1. Étape 1. Extrayez des identifiants stables : task_gid, gid de projet, gid de section, assigné, permalien, et tout champ personnalisé qui encode dépôt ou branche.
2. Étape 2. Construisez idempotency_key à partir des métadonnées Asana (par exemple wh_asana_{delivery_id} ou un hachage déterministe si la plateforme omet un identifiant sur votre chemin).
3. Étape 3. Poussez vers la file partagée avec les champs que votre script de build attend déjà (repo, ref, correlation_id). Un preferred_mesh_node_id optionnel convient pour des files GPU, mais évitez le couplage dur si la flotte change.
4. Étape 4. Émettez un événement interne « build planifié » pour que les tableaux de bord montrent la profondeur de file avant qu’un Mac ne prenne le travail — utile quand plusieurs tâches bougent dans Asana en quelques secondes.

Si vous débutez avec la séparation passerelle / workers, suivez le guide de déploiement multi-nœuds MeshMac afin que la terminaison TLS, les secrets et les points de terminaison de file restent sur la passerelle pendant que les builders restent remplaçables.

La diffusion est l’endroit où les pools multi-nœuds dérapent : chaque Mac veut « gentiment » notifier Slack, Teams ou Google Chat. Choisissez un gabarit sortant unique porté par la passerelle pour que chaque fin d’exécution soit identique et la déduplication triviale.

Forme JSON minimale (chat ou webhook générique) que chaque worker remplit via la passerelle :

• build_id et idempotency_key
• task_gid plus titre lisible
• mesh_node_id, nom d’hôte, version Xcode ou toolchain
• status dans {queued,running,succeeded,failed,canceled}
• duration_ms, exit_code, et un log_tail plafonné (par exemple 2 derniers Ko)

En cas de failed, la passerelle (pas chaque nœud) assemble le résumé d’échec pour Asana : première ligne résultat, deuxième ligne cause probable (tests, signature, disque), lien vers les journaux internes. Les workers envoient les journaux riches vers le stockage objet ou votre stack ; Asana ne reçoit que la synthèse pour que les PM restent dans Asana sans clés SSH.

Pour un schéma parallèle avec un autre SaaS, réutilisez les mêmes noms de champs (identifiant ticket, clé d’idempotence, nœud maillage) : le transport change, la discipline de passerelle reste la même.

401 sur l’URL appelée par Asana

Vous avez rejeté le webhook côté passerelle : mauvais fichier secret, corps modifié avant le HMAC, ou proxy inverse qui réencode gzip. Reproduisez une requête en échec en préproduction avec la même pile périphérique, comparez la longueur d’octets à l’entrée de signature et vérifiez que le secret de poignée de main correspond au secret de signature stocké.

401 uniquement lors de la publication de commentaires vers Asana

Il s’agit de l’auth PAT ou OAuth sortante, pas de la signature webhook. Faites tourner les clés délibérément (401 ne doit pas signifier « réessayer indéfiniment »). Vérifiez que l’espace de travail du jeton correspond à la tâche, que les portées incluent la création de stories, et que la passerelle relit le fichier mis à jour sans descripteur obsolète.

429 sur l’API REST Asana

Vous dépassez les limites de débit de la plateforme ou la concurrence sortante de la passerelle est trop bavarde. Sérialisez les mises à jour de commentaires par tâche, appliquez un backoff exponentiel avec jitter, respectez Retry-After lorsqu’il est fourni, et fusionnez les avis d’échec dupliqués dans une courte fenêtre de déduplication.

429 sur les webhooks Slack, Teams ou Google Chat

Des nœuds MeshMac parallèles peuvent déclencher une ruée vers le chat lors d’incidents de masse. Centralisez les publications sortantes sur la passerelle, plafonnez les clients webhook concurrents, backoff avec jitter, et dédupliquez sur build_id plus issue pour qu’un seul flux sortant existe.

Doublons après déplacements rapides entre colonnes

Resserrez la table de routage : exigez un champ personnalisé stable « prêt à builder » ou un anti-rebond sur les transitions de section. Combinez le gid de tâche, la section cible et un compartiment de cinq minutes dans la clé d’idempotence pour que les ajustements humains n’enfilent pas deux builds.