In base allo SES API Reference per SendRawEmail, gli unici parametri forniti come parte della richiesta sono un elenco di destinatari, il corpo dell'email e l'indirizzo di origine. Sfortunatamente, sembra molto chiaro che se si ottiene un timeout anziché una risposta da SES, c'è in nessun modo per sapere se è stata inviata quella particolare email. So che è molto sconvolgente. Lo odio anche quando mi trovo in quella situazione.
Si do, tuttavia, avere alcune opzioni quando si tratta di capire la soluzione più pratica per questo dilemma. Puoi prendere una decisione generale per non riprovare mai e assumere che un messaggio non inviato sia migliore di un messaggio duplicato. Puoi anche prendere una decisione generale che duplicare le email è assolutamente accettabile. Tuttavia, il mio approccio preferito e raccomandato è la via di mezzo meno accademicamente soddisfacente, ma pragmatica. Lasciatemi spiegare.
Quando si integra con un nuovo servizio e si trova un caso limite che non si sa come gestire ma che non si prevede si verifichi molto spesso, la cosa migliore da fare è raccogliere maggiori informazioni e gestire le cose manualmente in nel frattempo. Roma non è stata costruita in un giorno e il tuo servizio cloud non funzionerà perfettamente il primo giorno in cui lo accendi. Invece, quando si ottiene un timeout, registrarlo e salvare via qualsiasi cosa potrebbe essere necessario inviare di nuovo l'e-mail in seguito.
Ora immagina di aver terminato la codifica e di aver eseguito test di integrazione e che hai attivato il servizio in produzione. Il primo giorno, provi a inviare 100.000 email. Se ricevi 1000 timeout, qualcosa di veramente strano sta succedendo e sai che devi investigare sulla tua rete! Cosa succede se, invece, il primo giorno, ricevi 0 timeout, lo stesso il secondo giorno, e poi il settimo giorno, su 700.000 tentativi per la settimana, c'era solo 1 timeout. Se appropriato, puoi provare a chiamare quel 1 cliente e dire "Ciao, mi dispiace disturbarti, ma siamo davvero impegnati nell'affidabilità e abbiamo riscontrato un problema tecnico. Volevo assicurarmi di avere ricevuto la ricevuta di posta elettronica per [XYZ]. " Se dicono di no, beh, allora potrebbe essere sensato tornare indietro e cambiare il codice in modo che quando c'è un timeout, riprovi dopo aver atteso qualche secondo poiché sai che probabilmente funzionerà. La stessa idea per qualsiasi cosa nel mezzo.
Il punto qui è che applicherete la vostra intelligenza umana al mistero. Ho scoperto che è spesso più facile NON provare a fare i conti con l'ignoto. Preparati per essere in grado di gestire qualsiasi cosa accada, e capire qual è la cosa più intelligente da fare quando sai come si presenta il problema.
(Si può godere di questo blog post - scritto da qualcun altro -. A proposito di "non gestire casi limite")
Si sta utilizzando un AWS SDK per inviare e-mail in questo momento? Sto usando PHP SDK e dopo che SendEmail è stato attivato, c'è una risposta che indica se l'email è stata inviata o meno (controlla https://github.com/aws/aws-sdk-php/blob/master/src/ Aws/Ses/Resources/SES-2010-12-01.php).Quindi potrei registrare quel risultato e la prossima cosa è abbastanza semplice. –
@Hieu Sì, sì, e sì Amazon restituisce lo stato dell'invio. Il mio punto è, se la mail è * non * inviata perché, ad esempio, la richiesta HTTP non riceve una risposta, o PHP termina con un errore fatale, o qualcosa del genere, quindi non c'è modo di sapere se ho bisogno di inviare la email di nuovo o no. Ho un cron batch che elabora le e-mail in sospeso e vorrei poter chiedere "È già stata inviata un'email con l'ID 123?" – Benjamin
Hmm quindi in SDK è possibile utilizzare il metodo GetSendStatistics() che recupera le statistiche di utilizzo. Leggi di più qui: "Monitoraggio delle statistiche di utilizzo utilizzando l'API di Amazon SES" http://docs.aws.amazon.com/ses/latest/DeveloperGuide/monitor-usage-statistics.html. Spero che sia d'aiuto;) –