Fix run
Un fix run è l'agente che lavora una issue. Ogni issue ne riceve al massimo uno: un thread di tipo fix_run che raggiunge il verdetto e, su un problema confermato, continua a lavorarlo fino a una correzione nella stessa conversazione.
Cosa fa
Il thread è dove leggi l'intera storia: il lavoro mentre avviene, le evidenze a un clic di distanza nella sua discendenza e l'esito alla fine. Il run legge l'alert o il risultato, la query dietro di esso, metriche e log recenti intorno all'attivazione, le modifiche recenti e il tuo codice. Prima di agire, scrive la catena causale nel thread: il segnale, il meccanismo, il componente e il percorso nel codice che lo producono, l'innesco e il raggio d'impatto, ogni anello sostenuto da evidenze nominate o marcato come sconosciuto.
Come funziona
- Un run parte quando un controllo o un alert collegato produce un risultato, quando un agente in un thread di chat apre una issue dal problema di cui state parlando, oppure quando scegli Investigate su una issue.
- L'agente legge le evidenze e raggiunge uno di due verdetti,
confirmedodismissed. Un risultato che corrisponde a una issue esistente si unisce a quella invece di avviare un secondo run. - Su un problema confermato, lo stesso agente risale alla causa e scrive la catena causale.
- Quando una modifica al codice corregge la causa in un repository collegato, il run apre la pull request tramite autofix. Quando nessuna pull request può correggerla, il run solleva un'escalation che indica cosa deve fare una persona.
- Ogni passo finisce nella timeline delle attività della issue, accanto a rilevamenti, nuovi rilevamenti e le tue note.
Esiti
Dopo ogni turno dell'agente, Polylane classifica il run.
| Esito | Descrizione |
|---|---|
resolved | Causa radice trovata e problema corretto o ripristinato. |
diagnosed | Causa radice trovata, ma la correzione non è ancora arrivata. |
inconclusive | L'agente non è riuscito a stabilire una causa. |
false_positive | Il risultato non indicava un problema reale. |
failed | Il run è terminato con un errore. |
Un run può anche parcheggiarsi, il che impedisce al monitoraggio di sollecitarlo a indagare di nuovo finché la issue non si risolve.
| Stato di parcheggio | Descrizione |
|---|---|
needs_human_action | La correzione richiede qualcosa che solo tu puoi fare. |
needs_decision | L'agente ha bisogno di una tua decisione prima di continuare. |
awaiting_change | L'agente aspetta che una correzione venga rilasciata, ad esempio una pull request in attesa di revisione. Questo stato si parcheggia in silenzio. |
failed | Il run ha incontrato un errore che non è riuscito ad aggirare. |
I tre stati che richiedono una persona vengono registrati come escalation, mostrati sulla card dell'esito nel thread ed elencati sotto il preset Needs you, così la stessa richiesta non ti notifica mai due volte.
Dove trovare i fix run
I fix run compaiono sotto Threads accanto ai thread di chat, e il preset Needs you elenca quelli in attesa di una persona. La Lineage nella barra laterale del thread contiene il record dietro il run: Issue apre le evidenze e la timeline della issue, Escalation apre ciò che l'agente ti ha chiesto con Mark as handled, e Check apre la valutazione che ha rilevato il problema. Il menu della issue contiene Investigate, Investigate again, View investigation e View triggering check.
Configurazione
Sotto Settings > Workspace, la card Investigations imposta Investigate automatically from: la gravità più bassa che avvia un fix run da sola. Le issue sotto di essa conservano il loro verdetto e vengono trattenute, e il loro thread offre Start investigation così qualcuno del tuo team può prenderle in carico. I verdetti non vengono mai trattenuti: ogni issue confermata è visibilmente confermata, e la soglia rinvia solo il lavoro che segue.
Correlati
- Issue per il record che ogni fix run lavora.
- Threads per leggere, fermare e condividere il run.
- Escalations per le richieste che un run parcheggiato solleva.
- Autofix per la pull request che un run apre.