Exécutions
Comment une exécution d'agent est mise en file d'attente, exécutée, arrêtée et relancée.
Chaque fois qu'un agent commence à travailler, Multica crée une exécution qui enregistre ce qui a déclenché le travail, à quel agent il a été confié, où il en est et s'il a réussi.
Tâches et exécutions
Une tâche contient l'objectif, la discussion, l'assigné et le statut final d'un travail ; une exécution correspond à un passage d'un agent sur ce travail.
| Tâche | Exécution | |
|---|---|---|
| Ce qu'elle enregistre | Un travail qui avance | Un passage d'agent |
| Durée de vie | Peut être discutée, modifiée et réassignée à plusieurs reprises | Du déclenchement jusqu'à l'achèvement, l'échec ou l'annulation |
| Cardinalité | Une tâche peut couvrir de nombreuses exécutions | Chaque exécution a son propre enregistrement |
Une même tâche peut être confiée successivement à différents agents, ou relancée après un échec. Chaque passage produit un nouvel enregistrement d'exécution ; les enregistrements précédents ne sont jamais écrasés.
Sources de déclenchement
Chacun des éléments suivants déclenche une exécution :
- Assigner une tâche à un agent ou à un squad.
- Mentionner un agent dans un commentaire.
- Envoyer un message à un agent dans une discussion.
- Une automatisation qui se déclenche selon une planification ou à partir d'un événement externe.
- Un réveil de tâche dont l'événement, l'heure ou la condition arrive.
Selon le point d'entrée, l'agent reçoit un contexte différent, mais l'exécution fonctionne de la même façon : Multica crée une exécution, un runtime la prend en charge, et le runtime invoque l'outil de codage IA configuré pour l'agent.
Cycle de vie d'une exécution
Une exécution passe généralement par ces états :
| État | Signification |
|---|---|
deferred | Programmée pour plus tard ; entre dans la file d'attente à l'heure prévue |
queued | En attente de prise en charge par un runtime |
dispatched | Un runtime l'a prise en charge et démarre l'outil de codage IA |
waiting_local_directory | Le répertoire local cible est occupé par une autre exécution ; attente de la libération du verrou du répertoire |
running | L'outil de codage IA est en cours d'exécution |
completed | L'exécution s'est terminée normalement |
failed | L'exécution a rencontré une erreur ou a été interrompue |
cancelled | L'exécution a été arrêtée manuellement |
Lorsque le runtime est en ligne, une nouvelle exécution démarre généralement rapidement ; si le runtime passe hors ligne après l'entrée de l'exécution dans la file d'attente, l'exécution reste en file d'attente jusqu'à son rétablissement. Une longue attente ne fait pas expirer une exécution en file : un runtime qui continue d'envoyer ses signaux de vie (heartbeats) est occupé, pas disparu, et son arriéré peut s'écouler aussi longtemps que nécessaire. Une exécution en file d'attente n'échoue que lorsque les deux conditions sont réunies : son runtime est silencieux depuis plus longtemps que le délai de grâce de reconnexion, et l'exécution elle-même est en file d'attente depuis aussi longtemps. La seconde condition couvre le travail assigné à une machine déjà en veille : au lieu d'échouer immédiatement, l'exécution vous laisse un délai de grâce complet pour réveiller la machine.
Si le système sait déjà, avant le déclenchement, que le runtime cible est hors ligne, certaines actions immédiates indiquent que l'exécution ne peut pas démarrer pour le moment au lieu de créer une exécution que personne ne pourra prendre en charge.
Un runtime dont le signal de vie est sain peut mener de longues exécutions ; le serveur ne met jamais fin de force à une exécution simplement parce qu'elle dure depuis un moment. Le runtime détermine si le processus est bloqué en fonction de l'activité réelle ; consultez Variables d'environnement pour les réglages correspondants.
Consulter l'historique des exécutions
Toutes les exécutions produites par une tâche sont listées dans la section Journal d'exécution de la barre latérale droite de la tâche. La section est dépliée par défaut : les exécutions actives restent épinglées en haut, suivies des 3 dernières exécutions terminées sous Récentes ; les plus anciennes s'ouvrent avec Ouvrir la chronologie. Chaque ligne indique la source du déclenchement, l'agent qui exécute et l'état. Si vous ne voyez pas la section, ouvrez la barre latérale avec le bouton de panneau dans l'en-tête de la tâche ; sur les écrans étroits, elle est repliée au départ.
Tant que la page est ouverte, le journal se met à jour via la connexion temps réel : les nouvelles exécutions, les changements d'état et les commentaires de l'agent apparaissent sans rechargement.
Pendant qu'un agent travaille, l'en-tête de la tâche affiche aussi une pastille en direct, par exemple « Engineer travaille ». La survoler affiche les mêmes exécutions actives, ce qui permet de suivre la progression sans quitter la page.
Dans le journal d'exécution, vous pouvez :
- Cliquer sur Voir la transcription sur une ligne pour voir les messages de l'agent, les appels d'outils et la sortie d'erreur. Pour une exécution encore en cours, la transcription continue de s'afficher en direct tant que la boîte de dialogue reste ouverte, et un bouton Plus récents d'abord inverse l'ordre des événements.
- Arrêter les exécutions en file d'attente, en démarrage, en attente d'un répertoire local ou au travail.
- Relancer une exécution en échec ou annulée.
La démo ci-dessous parcourt un cycle complet : une exécution entre en file, démarre et échoue ; vous la relancez et la nouvelle exécution se termine. Une fois la nouvelle exécution lancée, vous pouvez aussi essayer de l'arrêter en cours de route.
Changer l'assigné ou le statut d'une tâche n'arrête pas une exécution déjà démarrée. Pour en interrompre une, arrêtez-la dans le journal d'exécution. Supprimer une tâche annule ses exécutions actives.
Le journal d'exécution totalise aussi le Dépensé, les Tokens et le Travail d'agent de la tâche, avec une barre de coût par exécution. Cliquer sur le total, sur une barre ou sur Ouvrir la chronologie ouvre la boîte de dialogue Exécutions, qui montre le coût par exécution ou en cumul, le répartit par agent et par modèle, et compte les exécutions en échec et annulées. Les coûts sont des estimations ; leur calcul et la consommation de tout l'espace de travail sont décrits dans Statistiques.
Échecs et relances automatiques
Les défaillances transitoires — un runtime brièvement hors ligne, un redémarrage du daemon, un délai d'exécution dépassé ou une interruption réseau dans l'outil de codage IA — peuvent déclencher une relance automatique. Par défaut, une exécution ordinaire est tentée au plus deux fois ; les interruptions réseau de l'outil ont droit à trois tentatives au maximum.
Les erreurs renvoyées par l'agent lui-même ne sont généralement pas relancées automatiquement. Identifiants expirés, quota épuisé, mauvaise configuration ou modèle incapable de traiter la requête : il faut d'abord corriger la cause, puis relancer manuellement.
Le mode Exécution seule d'une automatisation ne relance pas automatiquement, pour éviter tout chevauchement avec la prochaine exécution planifiée. Le mode Créer une tâche produit des exécutions de tâche ordinaires, donc les défaillances d'infrastructure sont toujours relancées selon les règles ci-dessus. Les deux modes affichent leur résultat final dans l'historique des exécutions de l'automatisation.
Lorsqu'une tâche n'a aucune autre exécution active et aucune nouvelle relance en attente, un échec fait repasser une tâche in_progress à todo.
Référence des motifs d'échec
Les motifs d'échec affichés dans le journal d'exécution et dans les Statistiques se répartissent en deux groupes : les codes sans préfixe sont enregistrés par la plateforme ; les codes agent_error.* sont classés à partir des erreurs propres à l'outil de codage IA.
| Motif | Signification | Que faire |
|---|---|---|
runtime_offline | Le runtime est passé hors ligne pendant l'exécution | Rétablissez le runtime et relancez ; voir Daemon et runtimes |
queued_expired | Le runtime a cessé d'envoyer des signaux de vie pendant plus longtemps que le délai de grâce de reconnexion, et l'exécution était aussi en file d'attente depuis aussi longtemps | Vérifiez que le runtime est en ligne, puis relancez |
runtime_recovery | Le daemon a récupéré une exécution interrompue après son redémarrage | Relancez directement |
environment_prepare_failed | Le daemon n'a pas pu préparer l'environnement d'exécution — son répertoire de travail, ou la configuration locale du runtime qui y est écrite | Lisez l'erreur brute pour savoir quelle étape a échoué, puis vérifiez cette machine : espace disque, permissions, répertoire encore utilisé, ou configuration locale de l'outil de codage IA |
cancelled | Arrêtée manuellement, ou annulée avec un archivage ou une suppression | Rien à faire |
timeout | Dépassement de la limite de durée d'exécution configurée pour le daemon | Réduisez le périmètre de la tâche, ou ajustez agent_timeout du daemon |
iteration_limit | Plafond d'itérations d'une exécution atteint | Réduisez le périmètre de la tâche |
agent_blocked | L'agent a signalé qu'il ne peut pas continuer | Fournissez ce que son commentaire demande |
api_invalid_request | L'API de la plateforme a rejeté une requête invalide | Relancez ; signalez le problème s'il se reproduit |
codex_semantic_inactivity | Codex n'a produit aucune sortie utile pendant trop longtemps et a été jugé bloqué | Relancez, ou ajustez le délai d'inactivité de Codex |
Relance manuelle
Cliquer sur le bouton Relancer l'exécution d'une ligne du journal d'exécution invoque l'agent qui a traité cette exécution à ce moment-là. Même si la tâche a été réassignée depuis, la relance ne bascule pas vers le nouvel assigné.
Une relance conserve autant que possible les fichiers que l'exécution précédente a déjà écrits dans le répertoire local. Si la session d'origine est toujours sûre et que le même runtime prend en charge la relance, celle-ci poursuit aussi la session précédente. Les erreurs qui corrompent la session, comme un dépassement de contexte ou des requêtes invalides, démarrent plutôt une nouvelle session dans le répertoire de travail d'origine. Lorsque le répertoire d'origine n'existe plus, un nouveau répertoire de travail est utilisé.
Retrouvez l’exécution source, puis relancez-la depuis le CLI :
multica issue runs <issue-id> --full-id
multica issue rerun-task <run-id>Un UUID d’exécution complet permet d’omettre --issue ; un préfixe court exige --issue. La commande reprend l’agent et le contexte de déclenchement d’origine, avec les mêmes règles de continuité que le bouton de relance. Ajoutez --fresh pour démarrer une nouvelle session dans un nouveau répertoire de travail.
L’ancienne commande multica issue rerun <issue-id> est obsolète et masquée dans l’aide. Elle reste disponible pour les scripts existants et lance toujours l’assigné actuel avec une nouvelle session et un nouveau répertoire de travail.
Fin d'exécution et fin de tâche
completed signifie seulement que cette exécution précise s'est terminée normalement ; cela ne confirme pas que l'objectif de la tâche est atteint. Une fois l'exécution finie, vous pouvez toujours examiner le résultat, poursuivre la discussion, ajouter des exigences ou déclencher à nouveau l'agent. C'est le statut de la tâche qui indique si elle est terminée.
Référence rapide des états et délais
Les valeurs ci-dessous sont celles de la configuration par défaut du serveur.
| État | Signification | Délai et conséquence |
|---|---|---|
deferred | Programmée pour plus tard | Passe à queued à l'heure prévue, puis les règles ci-dessous s'appliquent |
queued | En attente de prise en charge par un runtime | Attend tant que son runtime continue d'envoyer des signaux de vie, et dans tous les cas au moins un délai de grâce de reconnexion après la mise en file d'attente ; n'échoue que lorsque les deux fenêtres sont écoulées, et n'est pas relancée automatiquement |
dispatched | Prise en charge ; l'outil démarre | Considérée comme en échec après plus de 5 minutes dans cet état |
waiting_local_directory | En attente de la libération du verrou du répertoire local | Pas de délai propre ; reprend le processus de démarrage une fois le répertoire libéré |
running | L'outil de codage IA est en cours d'exécution | Pas de durée maximale fixe ; la vivacité suit le signal de vie du runtime — un toutes les 15 secondes ; un runtime qui perd son signal de vie est marqué hors ligne au plus tard en 3 minutes environ. Ses exécutions n'échouent qu'une fois le signal de vie absent au-delà du délai de grâce de reconnexion (MULTICA_RUNTIME_RECONNECT_GRACE, 3 heures par défaut) ; un redémarrage du daemon les récupère directement |
La relance automatique ne couvre que les défaillances transitoires ci-dessous, et ne s'applique qu'aux exécutions rattachées à une tâche ou à une discussion (hors mode Exécution seule des automatisations) :
| Motif d'échec relancé automatiquement | Nombre maximal de tentatives |
|---|---|
| Runtime hors ligne | 2 par défaut (première exécution + 1 relance) |
| Récupérée après un redémarrage du daemon | 2 par défaut |
| Délai d'exécution dépassé, selon la plateforme | 2 par défaut |
| Codex bloqué sans sortie utile | 2 par défaut |
| Échec du téléchargement du bundle de skills | 2 par défaut (le processus de l'agent n'a pas encore démarré à ce stade ; les bundles déjà téléchargés proviennent du cache local) |
| Interruption réseau de l'outil | Jusqu'à 3 ; la dernière tentative démarre après un délai d'environ 5 secondes |
Tous les autres motifs d'échec (authentification, quota, configuration, modèle, etc.) ne sont jamais relancés automatiquement ; corrigez d'abord la cause, puis relancez manuellement.
Étapes suivantes
- Daemon et runtimes — sur quel ordinateur une exécution s'effectue.
- Assigner des tâches aux agents — déclencher une exécution depuis une tâche.
- Mentionner des agents — ajouter des exigences dans les commentaires ou faire intervenir d'autres agents.
Recherche, raccourcis et préférences
Rechercher et exécuter des commandes avec ⌘K, consulter et modifier les raccourcis clavier, chercher du texte dans une tâche et régler vos préférences personnelles comme le thème, la langue et le fuseau horaire.
Daemon et runtimes
Comment Multica connecte les ordinateurs, détecte les outils de codage IA et lance les exécutions.