Runbook: diagnosticare un'operazione provider fallita o ambigua

Quando usarlo

Usare questo runbook quando un attempt Campaign Draft è failed o unknown, oppure una ricevuta provider è incompleta o non univoca.

Prerequisiti

• aggregate e attempt leggibili;
• provider mode e operation type noti;
• evidenza sanitizzata disponibile;
• nessun retry già avviato;
• autorizzazione separata per eventuale riconciliazione o nuovo attempt.

Procedura

1. Fermare scheduling, upload successivi e delivery.
2. Rileggere l'aggregate e tutti gli attempt dell'Issue.
3. Identificare prepare o content_upload, provider mode e parent.
4. Distinguere failed da unknown.
5. Verificare se il server offre un'azione di retry o una lettura provider.
6. Per unknown, preferire una riconciliazione read-only quando supportata.
7. Confrontare draft, campaign e provider status senza copiare payload privati.
8. Se il risultato resta ambiguo, terminare senza retry.
9. Se un retry è autorizzato e proiettato, crearne uno solo come nuovo attempt.

Verifiche attese

• attempt originale immutato;
• nessuna duplicazione nascosta;
• retry, se presente, collegato al parent;
• evidenza sanitizzata;
• stato finale coerente con ciò che il provider dimostra;
• nessuna interpretazione di unknown come successo.

Condizioni di stop

Fermarsi se servono credenziali o dati destinatario nei log, l'ID provider non è autorevole, esistono più operazioni compatibili, l'azione non è proiettata o la riconciliazione richiederebbe una mutazione.

Rollback o recupero

Un Campaign Draft non ha un rollback applicativo generico. Mantenere l'aggregate e l'audit, annullare soltanto tramite una futura operazione esplicitamente supportata e aprire un Issue di recupero se lo stato provider non può essere determinato.

Evidenza da conservare

• aggregate e attempt interessati;
• operation type e provider mode;
• stato prima e dopo;
• codice, fase e HTTP status sanitizzati quando disponibili;
• retry o riconciliazione usati;
• conclusione esplicita: riuscita, fallita o non provata.