[AI] - CODEX - Che cos'e' una sessione watchdog

Il watchdog e' una sessione, nel mio caso sto utilizzando Codex, parallela che osserva una lavorazione critica senza partecipare allo sviluppo. 

Il suo compito non e' correggere, ma garantire che un test lungo o rischioso non resti appeso senza controllo. Lavora con regole scritte, soglie misurabili e privilegi minimi.

La possiamo descrivere come una sessione di sorveglianza parallela, separata dalla sessione che lavora davvero sui test.

Nel nostro caso la sessione “Verifica presenza”, su codex utilizzando chatgpt, eseguiva i test operativi di uno  schedulatore, ORA_SCHED. 

La sessione “watchdog”, invece, non sviluppava, non correggeva codice e non lanciava test autonomamente: osservava soltanto se la sessione principale stava avanzando oppure se si era bloccata.

Funzionamento
Il watchdog lavora come un supervisore esterno:

1. Legge un file di regole operativo, nel nostro caso WATCHDOG_TEST_SCHEDULATORE_.md
2. Controlla periodicamente processi OS, log applicativi, job Oracle e stato delle prenotazioni di test.
3. Decide se c’e' avanzamento reale oppure un possibile blocco.
4. Interviene solo se le condizioni di hang sono soddisfatte.
5. Produce un report finale con processi osservati, job running, stati DB e azioni fatte.

La cosa importante e' che il watchdog non giudica il risultato funzionale dei test. Se una prenotazione finisce in errore applicativo, non e' automaticamente un problema per il watchdog. Diventa un problema solo se il sistema resta fermo: processo vivo troppo a lungo, log non aggiornati, job Oracle running oltre soglia, stati intermedi invariati.

• Regole di sicurezza

La forza della funzionalita' sta nei limiti espliciti:

• lavora quasi sempre in sola lettura;
• usa solo SELECT sul database;
• non modifica codice;
• non fa cleanup DB;
• non cancella log;
• non spegne la VM;
• non droppa job Oracle senza autorizzazione;
• puo' terminare solo processi OS appartenenti al kit di test, e solo se rileva un hang secondo regole gia' definite.

Quindi non e' “un secondo agente che improvvisa”. E' piu' simile a un supervisore con mandato ristretto: osserva, misura, segnala, e interviene solo dentro un perimetro autorizzato.

• Criterio di hang

Nel nostro file watchdog abbiamo definito alcune condizioni chiare:

• processo del kit vivo oltre 5 minuti senza variazione dei log;
• sqlplus del kit appeso oltre 5 minuti;
• job Oracle di test running oltre 5 minuti;
• prenotazioni 990100-990299 ferme in stato intermedio oltre 5 minuti;
• timeout dichiarato dalla sessione principale;
• comando utente esplicito, per esempio blocca tutto.

Questo rende l’intervento ripetibile e verificabile: il watchdog non ferma qualcosa “a sensazione”, ma perche' una soglia operativa e' stata superata.

• Esempio pratico

Durante il test A00 il watchdog ha visto varie fasi:

• polling iniziale;
• esecuzione expdp;
• test di concorrenza 990120 / NTCONC;
• test di parallelismo 990201-990205 / NTPAR1..5.

In ogni fase ha controllato processi, job e log. Quando vedeva timestamp aggiornati, processi giovani o stati DB che cambiavano, non interveniva. 

Alla fine ha confermato che non c’erano processi residui, nessun job Oracle running e nessuna prenotazione intermedia.