Runbook: recuperare un job di generazione fallito

Quando usarlo

Usare questo runbook quando un job è failed, il polling è terminato senza esito visibile o la Queue ha redeliverato un comando.

Prerequisiti

job ID e Topic ID;
lettura Admin del job D1;
accesso alle risorse editoriali necessarie;
nessuna assunzione che 202 Accepted o redelivery significhino successo;
autorizzazione per creare un eventuale nuovo job.

Procedura

Rileggere il job dall'API.
Se è queued o running, non creare un duplicato; riprendere il monitoraggio bounded.
Se è completed, verificare Issue ID, slug e Topic; terminare senza retry.
Se è failed, classificare il codice:
Topic o copertura: correggere D1;
configurazione provider: correggere fuori dal job;
output invalido: valutare input e creare un nuovo job;
enqueue: verificare che nessun Issue sia stato creato.
Rileggere Topic e Knowledge Asset dopo la correzione.
Creare un solo nuovo job esplicito.
Monitorare e verificare l'Issue associato.

Verifiche attese

il job originale resta terminale e immutato;
un eventuale retry ha un nuovo job ID;
nessun Issue duplicato;
il nuovo successo produce un draft pending_review;
nessun output AI invalido è stato persistito.

Condizioni di stop

Fermarsi se lo stato D1 non è leggibile, esistono Issue duplicati non riconciliabili, la correzione richiede dati non accettati, il provider resta ambiguo o sarebbe necessario modificare manualmente lo stato del job.

Rollback o recupero

Non esiste rollback del provider AI. Se un Issue valido è già stato creato, usarlo soltanto quando slug e Topic coincidono. Altrimenti aprire un Issue di recupero; non associare il job a un contenuto diverso.

Evidenza da conservare

job originale e codice sicuro;
autorità corretta prima del retry;
nuovo job eventuale;
Issue associato e stato;
numero di operazioni create;
conferma di zero pubblicazioni, Mailjet o delivery.