Runbook: interrompere un Campaign Draft ambiguo
Quando usarlo
Usare questo runbook quando il job durevole è operator_required, l'aggregate
applicativo è recovery_required, un attempt provider è unknown, oppure una
risposta provider è arrivata ma la proiezione D1 non è stata confermata. Il
Workflow e l'EmailCampaignService restano fail-closed internamente: l'operatore
non chiama recover, replace, deliver o reconcile. Prima di intervenire,
verificare lo stato con le letture bounded.
Prerequisiti
- identità autorizzata a
email:campaigns:reade, per l'abort,email:campaigns:abort; - Issue e target allowlisted riletti dall'API;
- aggregate, correlation ID e storia attempt correnti;
- motivo bounded privo di indirizzi o dati personali.
Procedura
- Leggere
get_email_campaign_job,get_email_campaigneget_email_campaign_attempts. Fermarsi se esiste già uno stato terminale autorevole. - Facoltativamente chiamare
render_email_campaign_contentper verificare subject, HTML e testo canonici. Questa lettura non dipende dalla configurazione Mailjet e non modifica una campagna. - Se il workflow non deve proseguire, chiamare
abort_email_campaignconconfirmation: "abort"e un motivo bounded. Se esiste un provider draft noto, l'API verifica che appartenga al sender e target configurati e che sia ancoraDraft. Il draft Mailjet resta conservato perché l'API Campaign Draft non espone una cancellazione; l'audit registraretained_provider_draft. - Se un nuovo invio è ancora richiesto, chiamare
schedule_newslettercome nuova intenzione. Non esiste un tool operatorreplace.
Condizioni di stop
Fermarsi senza retry su zero o più candidati, correlation mismatch, subject o
target mismatch, sender non proprietario, contenuto presente ma diverso dal
canonico, stato provider diverso da Draft o Programmed, schedule diversa da
quella esplicitamente richiesta, readback provider ambiguo, o campaign già
scheduled per un abort.
Non cancellare record o attempt, non modificare direttamente D1, non ripetere una mutazione Mailjet e non usare la disponibilità di un tool come prova di autorizzazione operativa.
Evidenza da conservare
- campaign ID applicativo e stato iniziale/finale;
- attempt immutabile con fasi, durata e codice sanitizzato;
- motivo di abort e disposizione del draft provider;
- job ID se presente, senza credenziali o payload provider.