Temporal orchestre en durable ; les activités vers OpenClaw restent du HTTP discipliné : liste blanche passerelle, heartbeats réalistes, résumés d’échec compacts sans transcriptions complètes. Cible : Mac Apple Silicon loué, loopback ou tunnel SSH.

Enchaînez avec Agno et liste blanche, sessions_spawn et Task Brain pour une corrélation unique entre files Temporal et journaux passerelle.

Sur cette page : Friction · Loopback / tunnel · Identité worker · Retry · Secrets · Modes passerelle · Étapes

Trois frictions que les équipes reproduisent encore

Un : Bearer valide mais catalogue vide si HTTP ou Session restent sur refus implicite. Deux : appels longs sans heartbeat — Temporal annule pendant que la passerelle finit, puis les retries dupliquent les effets. Trois : secrets dans l’entrée workflow, donc rejoués dans l’historique. Les H2 suivants posent les réglages.

Matrice de décision : boucle locale ou tunnel SSH vers la passerelle

Tranchez avant de figer l’environnement du worker : une URL de base stable après redémarrage launchd, rotation de certificat ou reprise sur incident. La matrice évite les fausses pistes « DNS public contre localhost » qui retardent les premières livraisons sur Mac loué.

Mode Cas d’usage Risque principal Atténuation
Boucle locale Même hôte macOS, cible 127.0.0.1. Collisions de ports sur le locataire. Ports figés launchd + nom de file documenté.
Port forwarding SSH local Autre namespace réseau, worker voit localhost. Tunnel silencieux, retries dupliquent les appels. Probe + idempotence workflow et tentative.
Mixte Cluster Temporal distant, OpenClaw sur le Mac. Horloge et logs fragmentés. Même corrélation Temporal et OpenClaw.

Si Temporal est dans le nuage et OpenClaw sur le Mac, la ligne mixte s’applique : gardez une corrélation unique entre tentative d’activité et ligne passerelle afin que le support relie chronologie Temporal et journaux HTTP sans interpolation manuelle.

Identité du worker

File de tâches stable par environnement, identité lisible dans l’UI Temporal, build id dès que les dépendances changent. Recopiez ces étiquettes dans la configuration OpenClaw ou les en-têtes de requête pour joindre durablement l’historique aux traces passerelle. Séparez files interactives et production afin que l’autoscale et les plafonds de retry restent prévisibles lors des démos internes ou des chargebacks.

Politique de retry

Le workflow reste déterministe : aucun appel OpenClaw direct. Placez HTTP, streaming et outils dans des activités avec politique de retry explicite, schedule-to-start resserré lorsque la file se remplit, et schedule-to-close supérieur au pire scénario modèle plus la file passerelle. Marquez validation et codes client 4xx comme non retentables. Un backoff exponentiel plafonné limite la tempête sur la passerelle lors des reprises collectives après panne réseau ou saturation GPU.

Injection de secrets

Chargez jetons Bearer, URL de modèle et identifiants de locataire depuis l’environnement du processus worker, un fichier de boot aux permissions strictes, ou un secret manager consulté au début d’activité. Évitez arguments de workflow, payloads d’enfant ou attributs de recherche pour ces secrets : ils se rejouent et voyagent dans les exports d’audit. Pour rotation, redémarrez le worker et laissez terminer les activités en vol plutôt que de muter une variable globale depuis du code rejoué.

Modes passerelle : boucle locale et tunnel en production

Boucle locale lorsque worker et écouteur OpenClaw partagent le même hôte macOS : ciblez 127.0.0.1 pour une latence prévisible. Tunnel via ssh -L : le code d’activité poste vers localhost pendant que sshd relaie vers le port réel lorsque la passerelle vit dans un conteneur ou une autre interface. Consignez le choix dans le README du service ; un mélange confus entre DNS public et loopback coûte cher en diagnostic. Dans les deux cas, alignez la liste blanche Agno sur les chemins réellement invoqués pour que le catalogue exposé au modèle corresponde au périmètre du jeton.

Étapes minimales reproductibles

Séquence sur le Mac distant avant horaires de prod ; chaque point laisse une trace pour la sécurité.

  1. Node 22 LTS, CLI OpenClaw, openclaw doctor, archive + namespace Temporal et empreintes TLS.
  2. Passerelle ou tunnel ; OPENCLAW_BASE_URL sur le couple hôte-port validé.
  3. Bearer court ; allowlists Session et HTTP sur tools/invoke et routes utiles.
  4. Activités : timeouts, heartbeats sur flux longs, retours typés exploitables par le workflow.
  5. Enregistrement file, identité, build id ; Temporal Cloud ou self-host en TLS.
  6. Chaos : couper tunnel ou port ; tentatives visibles ; JSON d’échec avec classes et ids, sans HTML.
  • Repère : intervalle heartbeat < timeout Temporal du namespace.
  • Repère : JSON d’échec petit pour un historique léger.
  • Repère : même corrélation OpenClaw et complétion d’activité.

FAQ

Transcriptions complètes dans le workflow ? Non : résumés ; traces brutes dans l’objet stockage par corrélation (voir sessions_spawn).

Temporal remplace la passerelle ? Non : retries côté orchestrateur ; visibilité outils côté OpenClaw.

Blog technique, accueil, puis tarifs et achat pour louer du M4 et rejouer ce runbook à l’échelle.

Résumé — orientation achat : identité et build id figés, activités avec heartbeats et retries bornés, secrets hors historique, loopback ou tunnel assumé, allowlist alignée au Bearer, JSON d’échec léger. Tarifs et achat publics sans compte pour chiffrer un Mac mini M4 dédié avant d’industrialiser vos workers.