Issues

Une issue est l'enregistrement unique d'un problème : quelque chose que les vérifications propres à Polylane ont trouvé, ou une alerte envoyée par un outil connecté. L'enregistrement tient les comptes (empreinte, occurrences, verdict, sévérité) ; le thread du fix run qui la traite est l'endroit où tu lis ce qui s'est passé.

Ce que ça fait

Chaque détection suit un seul cycle de vie, quelle que soit sa source : elle est enregistrée, un fix run atteint un verdict, un incident confirmé est traité jusqu'au correctif, et l'issue se résout quand le problème est terminé. Il n'y a pas de file d'alertes brutes à trier à la main. Les doublons se fondent dans l'issue qui existe déjà, donc un problème est un enregistrement et un thread.

D'où viennent les issues

Comment ça marche

1. Un constat est enregistré avec une empreinte construite à partir de sa source : la ressource et la vérification pour les détections Polylane, l'intégration et l'identifiant d'alerte pour les alertes de fournisseurs. Un déclenchement qui correspond à une issue ouverte incrémente son compteur d'occurrences au lieu de créer un doublon.
2. Un fix run lit la charge utile brute, la requête derrière l'alerte, les métriques récentes et ton code, puis enregistre l'un de deux verdicts : confirmed (un vrai problème) ou dismissed (du bruit ou un comportement attendu). Un constat qui appartient à une issue déjà ouverte, ou à une issue résolue récemment, rejoint cette issue à la place.
3. Une issue confirmée est traitée jusqu'au correctif dans le même thread, sauf si le seuil de sévérité de l'espace de travail ou la limite du forfait la retient pour qu'une personne la démarre. La sévérité est l'une de critical, high, medium, low ou info, et le run peut la réévaluer une fois qu'il a lu les preuves.
4. L'issue se résout quand le problème est terminé : un rétablissement côté fournisseur, une vérification ultérieure qui revient saine, ou une alerte qui reste silencieuse. Tu peux aussi la marquer Resolved toi-même. Si le même problème revient dans les 24 heures (plus longtemps pour les issues qui nomment un défaut de code), l'issue existante rouvre et son fix run y jette un regard neuf.

États

Une issue porte aussi resolvedAt une fois le problème terminé, quel que soit son état.

Où la trouver

Ouvre Issues dans la console pour parcourir les détections, filtrer par gravité ou état et retrouver les issues actives ou en attente. Chaque issue possède une page avec ses preuves, son investigation, sa chronologie et ses propriétés. Investigate démarre un run et Open thread permet de poursuivre la conversation. Le champ _html_url de l'API pointe directement vers cette page, même pour les issues sans run.

Sous Threads, le préréglage Fix runs liste les conversations avec l'agent. Le dernier message du run donne son résultat : une pull request, aucun correctif nécessaire ou une demande qui requiert ton attention. La barre latérale ouvre les preuves et toute escalade, avec Open full page pour afficher l'enregistrement complet.

Chaque compte cloud, intégration et ressource de topologie a un onglet Problems qui liste les fix runs sur ce périmètre. Une issue qui n'a jamais eu de run apparaît comme une carte dans le fil ; déplie-la et utilise Investigate pour en démarrer un. Depuis les scripts, l'issue est un objet à part entière dans la référence de l'API, lue avec le scope issues:read et modifiée avec issues:write.

Voir aussi

• Fix runs pour la façon dont un run atteint son verdict et traite une issue confirmée.
• Threads pour lire une transcription et ses preuves.
• Escalations pour ce qui se passe quand l'agent a besoin de toi.
• Clouds pour les comptes et les ressources auxquels les issues sont rattachées.