Fix runs
Un fix run est l'agent qui traite une issue. Chaque issue en a au plus un : un thread de type fix_run qui atteint le verdict et, sur un problème confirmé, continue de le traiter jusqu'au correctif dans la même conversation.
Ce que ça fait
Le thread est l'endroit où tu lis toute l'histoire : le travail au moment où il se fait, les preuves à un clic dans sa lignée, et le résultat à la fin. Le run lit l'alerte ou le constat, la requête derrière, les métriques et logs récents autour du déclenchement, les changements récents et ton code. Avant d'agir, il écrit la chaîne causale dans le thread : le signal, le mécanisme, le composant et le chemin de code qui le produisent, le déclencheur et le rayon d'impact, chaque maillon appuyé par une preuve nommée ou marqué comme inconnu.
Comment ça marche
- Un run démarre quand une vérification ou une alerte connectée produit un constat, quand un agent dans un thread de chat ouvre une issue à partir du problème dont tu discutes, ou quand tu choisis Investigate sur une issue.
- L'agent lit les preuves et atteint l'un de deux verdicts,
confirmedoudismissed. Un constat qui correspond à une issue existante la rejoint au lieu de démarrer un second run. - Sur un problème confirmé, le même agent remonte à la cause et écrit la chaîne causale.
- Quand un changement de code corrige la cause dans un dépôt connecté, le run ouvre la pull request via l'autofix. Quand aucune pull request ne peut le corriger, le run lève une escalade qui nomme ce qu'une personne doit faire.
- Chaque étape atterrit sur la chronologie d'activité de l'issue, à côté des détections, des redétections et de tes propres notes.
Résultats
Après chaque tour de l'agent, Polylane classe le run.
| Résultat | Description |
|---|---|
resolved | Cause racine trouvée et problème corrigé ou rétabli. |
diagnosed | Cause racine trouvée, mais le correctif n'est pas encore arrivé. |
inconclusive | L'agent n'a pas pu trancher sur une cause. |
false_positive | Le constat ne pointait pas vers un vrai problème. |
failed | Le run s'est terminé sur une erreur. |
Un run peut aussi se mettre en attente, ce qui empêche la surveillance de le pousser à réinvestiguer jusqu'à ce que l'issue se résolve.
| État d'attente | Description |
|---|---|
needs_human_action | Le correctif exige quelque chose que toi seul peux faire. |
needs_decision | L'agent a besoin d'une décision de ta part avant de continuer. |
awaiting_change | L'agent attend qu'un correctif soit livré, par exemple une pull request en attente de revue. Cet état se met en attente en silence. |
failed | Le run a rencontré une erreur qu'il n'a pas pu contourner. |
Les trois états qui ont besoin d'une personne sont enregistrés comme escalades, affichés sur la carte de résultat dans le thread et listés sous le préréglage Needs you, pour que la même demande ne te notifie jamais deux fois.
Où les trouver
Les fix runs apparaissent sous Threads à côté des threads de chat, et le préréglage Needs you liste ceux qui attendent une personne. La Lineage dans la barre latérale du thread contient l'enregistrement derrière le run : Issue ouvre les preuves et la chronologie de l'issue, Escalation ouvre ce que l'agent t'a demandé avec Mark as handled, et Check ouvre l'évaluation qui a détecté le problème. Le menu de l'issue porte Investigate, Investigate again, View investigation et View triggering check.
Configurer
Sous Settings > Workspace, la carte Investigations règle Investigate automatically from : la sévérité la plus basse qui démarre un fix run d'elle-même. Les issues en dessous gardent leur verdict et sont retenues, et leur thread propose Start investigation pour que quelqu'un de ton équipe puisse les reprendre. Les verdicts ne sont jamais retenus : chaque issue confirmée est visiblement confirmée, et le seuil ne diffère que le travail qui suit.
Voir aussi
- Issues pour l'enregistrement que chaque fix run traite.
- Threads pour lire, arrêter et partager le run.
- Escalations pour les demandes qu'un run en attente lève.
- Autofix pour la pull request qu'un run ouvre.