Ledger dei fallimenti per test email in Cypress batte i retry lunghi

“expected email, but none arrived.” Il run dopo passa. Il team alza i retry. Una settimana più tardi lo stesso test fallisce per un altro motivo e nessuno sa quale segnale seguire¹.

Un “failure ledger” risolve il buio tra tentativi. Registra cosa ha chiesto il test, cosa ha risposto la mailbox, e perché l’asserzione ha accettato o rifiutato un messaggio. In Cypress serve ancora di più, perché il processo del browser e il task Node hanno ruoli diversi e vanno documentati in modo coerente¹. Non archiviare ogni email. Conserva prove sufficienti per permettere al QA di classificare il fallimento senza rilanciare la pipeline più volte¹.

Il retry dice se più tardi è andata. Non spiega se il primo tentativo ha usato un messaggio stantio, se ha letto l’inbox sbagliata, se ha oltrepassato il confine di consegna, o se c’è una regressione reale¹. Esempio: il test di reset password invia alle 10:02:14. Il poller vede alle 10:02:16 un reset più vecchio e lo accetta. Un’altra volta scade il timeout perché il nuovo messaggio arriva appena fuori finestra. Sembrano flakiness di consegna, ma le correzioni sono diverse¹.

Tratta ogni tentativo come una piccola transazione con id, orario di trigger, lease della mailbox e decisione finale. Così anche una temp mail o un alias di test restano diagnosticabili senza fare della mailbox la fonte di verità¹. Nel ledger salva: nome del test, job CI, browser, worker e numero di retry. Usa un id stabile della mailbox, non l’indirizzo intero. Registra il timestamp subito prima dell’azione dell’applicazione. Annota i filtri per mittente, oggetto, destinatario ed età del messaggio. Elenca gli id dei messaggi visti e gli orari di ricezione. Spiega il motivo di accettazione o rifiuto per ogni candidato. Chiudi con l’errore finale e il percorso dell’artifact¹.

Redigi i segreti. Non archiviare token di verifica o corpi completi, salvo indagini strettamente controllate e a tempo. Il principio è lo stesso delle email di recupero: conserva la prova dell’evento senza trasformare gli artifact CI in un deposito di credenziali¹. Registra anche quando la mailbox viene allocata e rilasciata. Se la condivide un altro worker non è solo lentezza, è una rottura del contratto di isolamento¹.

In Cypress scrivi il ledger con un task Node. Il task riceve dati già redatti e ritorna una conferma breve. Non deve prelevare segreti dal contesto browser¹. Mantieni un runId stabile per l’intero tentativo, e includi il numero di retry nel record, altrimenti il secondo tentativo sovrascrive silenziosamente il primo. In parallelo aggiungi l’id della macchina o del worker¹.

Il poller segue una sequenza ripetibile: alloca una mailbox o un lease, salva il trigger prima dell’azione, polla fino a una deadline definita loggando gli id senza token, rifiuta messaggi anteriori al trigger o di altre run, accetta un solo messaggio quando recipient e regola di correlazione coincidono, scrive il ledger prima di rilasciare la mailbox in caso di fallimento¹. Usa una scadenza ragionevole: un timeout enorme trasforma un outage del provider in un outage lento del CI, uno minuscolo fa sembrare rotta una consegna normale. Il valore deve riflettere il comportamento osservato e deve comparire nel ledger¹.

Prima di alzare i retry, rispondi a domande mirate: il test ha posseduto la mailbox per tutto il tentativo? Il trigger è stato salvato prima dell’azione? Un messaggio più vecchio poteva soddisfare il selettore? Un altro worker ha visto o consumato lo stesso messaggio? Il messaggio è arrivato dopo la deadline? Il ledger spiega ogni rifiuto? Si riproduce col runId? Se non sai rispondere, migliora il ledger prima di toccare le attese¹.

Evita di trasformare termini come “dummy e mail” o “temp mailid” in criteri di accettazione o nomi di mailbox nei test. Tienili solo come alias di ricerca¹.