Awarie e-maili transakcyjnych

Pierwsze 15 minut

1. Zbadaj szczegóły DeliveryDelay w Amazon SES, w tym odbiorcę, rozszerzony status, diagnostykę, typ opóźnienia, czas zdarzenia i czas wygaśnięcia, gdy publikowanie jest włączone.
2. Zmierz opóźnienie od żądania do dostawcy, od dostawcy do dostarczenia i od dostarczenia do kliknięcia w stosunku do czasu życia tokenu.

Teraz

• Wydaj nowo wygenerowany token przez ścieżkę ponownego wysłania z limitem częstotliwości, gdy opóźniona wiadomość już wygasła.

Najbliższe 24 godziny

• Utrzymuj wcześniejsze tokeny resetowania jako nieważne po użyciu lub wymianie zgodnie z modelem zaległych tokenów w aplikacji.

Najbliższe 7 dni

• Ustaw budżet ponowień i alertów specyficzny dla resetowania krótszy niż skonfigurowany czas życia tokenu.

Kontrole techniczne

Kryteria weryfikacji

• Zmierzone opóźnienie od żądania do dostawcy, od dostawcy do dostarczenia i od dostarczenia do kliknięcia pozostaje w skonfigurowanym czasie życia tokenu dla testowanego przepływu.

Kryteria eskalacji

• Eskaluj do ESP, gdy diagnostyka DeliveryDelay pokazuje, że kolejka dostawcy zbliża się do wygaśnięcia przed budżetem specyficznym dla resetowania.

Zapobieganie

• Używaj jednorazowych tokenów resetowania z czasem życia dobranym do modelu zagrożeń aplikacji i doświadczenia odzyskiwania.
• Monitoruj każdy segment opóźnienia pod kątem wygaśnięcia tokenu, zamiast polegać wyłącznie na akceptacji przez dostawcę.
• Utrzymuj budżet ponowień i alertów dla resetowania krótszy niż czas życia tokenu.

Wpływ na biznes

• Użytkownicy mogą otrzymywać bezużyteczne linki odzyskiwania, ponieważ ogólne okna ponowień SMTP mogą przekraczać odpowiedni czas życia jednorazowego tokenu.

Uwagi dostawcy

• Zdarzenia DeliveryDelay w Amazon SES zawierają diagnostykę opóźnienia i czas wygaśnięcia tylko wtedy, gdy to publikowanie zdarzeń jest włączone.

Otwarte pytania

• Skonfigurowane TTL tokenu, obserwowany rozkład opóźnień, harmonogram ponowień i etap opóźnienia nie zostały podane.
• MTA ESP i odbiorców używają różnych harmonogramów ponowień i zdarzeń opóźnienia, więc przykłady z RFC i SES nie ustalają rzeczywistego zachowania kolejki.

Pierwsze 15 minut

1. Sprawdź, czy zdarzenie zamówienia przeszło przez standardową kolejkę SQS, która może zwrócić tę samą kopię wiadomości więcej niż raz.
2. Porównaj klucze idempotencyjności dla zduplikowanych potwierdzeń i potwierdź, że ponownie użyto jednego stabilnego klucza typu zdarzenia i ID zamówienia.
3. Sprawdź, czy Resend zwrócił 409 dla zmienionego ładunku lub identycznego żądania z kluczem, które nadal jest w toku.

Teraz

• Ponownie użyj tego samego klucza idempotencyjności i ładunku Resend dla każdego ponowienia jednego żądania potwierdzenia zamówienia.

Najbliższe 24 godziny

• Wygeneruj stabilny klucz z typu zdarzenia i ID zamówienia, tak aby jedno zdarzenie zamówienia mapowało się na jedną logiczną wysyłkę.

Najbliższe 7 dni

• Utrzymuj współbieżne ponowienia na tym samym kluczu i ponów przypadek 409 w toku później z tym samym żądaniem.

Kontrole techniczne

Kryteria weryfikacji

• Powtórz to samo żądanie Resend z kluczem w udokumentowanym 24-godzinnym oknie przechowywania i potwierdź, że jest ono przetwarzane raz.
• Potwierdź, że klucz użyty ponownie z innym ładunkiem zwraca 409, a nie tworzy kolejną logiczną wysyłkę.
• Potwierdź, że identyczne żądanie z kluczem, które było w toku, może zostać ponowione później z tym samym żądaniem.

Kryteria eskalacji

• Eskaluj projekt ochrony przed duplikatami, gdy musi on obejmować okres dłuższy niż udokumentowane 24-godzinne przechowywanie klucza idempotencyjności w Resend.
• Eskaluj do ESP, gdy obserwowane zachowanie 409 różni się od udokumentowanych przypadków zmienionego ładunku lub żądania w toku.

Zapobieganie

• Uczyń konsumentów standardowych kolejek idempotentnymi, aby ponowne dostarczenie wiadomości nie mogło tworzyć zduplikowanych efektów.
• Używaj tego samego klucza idempotencyjności dostawcy przy każdym ponowieniu.
• Wygeneruj jeden stabilny klucz typu zdarzenia i ID encji dla każdej logicznej wysyłki potwierdzenia zamówienia.

Wpływ na biznes

• Bez tego samego klucza idempotencyjności Resend przy każdym ponowieniu, powtarzające się żądania wysyłki nie są chronione przez udokumentowane zachowanie jednokrotnego przetwarzania.

Uwagi dostawcy

• Resend przechowuje klucze idempotencyjności e-maili przez 24 godziny.
• Resend zwraca 409, gdy klucz jest ponownie używany z innym ładunkiem lub gdy identyczne żądanie z kluczem jest nadal w toku.

Otwarte pytania

• Źródłem duplikatu mogą być powtarzające się zdarzenia zamówień, ponowne dostarczenie z kolejki, współbieżni workerzy, ponowienie HTTP lub różne klucze idempotencyjności; logi muszą je rozróżnić.
• Obsługa idempotencyjności API e-mail, przechowywanie kluczy i semantyka konfliktów różnią się w zależności od ESP; udokumentowane 24-godzinne zachowanie Resend nie jest uniwersalne.
• Obecny trwały rejestr wysyłek aplikacji i ograniczenia unikalności są nieznane.

Pierwsze 15 minut

1. Wyzwól szablony rejestracji i resetu hasła oddzielnie i oznacz każdy test według przepływu.
2. Dla każdego wyzwalacza odróżnij pomyślną akceptację API od przekazania do serwera odbiorcy, porównując zdarzenia wysłania i dostarczenia.
3. Zbadaj szczegóły zdarzeń opóźnienia dostarczenia i niepowodzenia przed przypisaniem przyczyny.

Teraz

• Skoryguj problem z nieprawidłowym odbiorcą, poświadczeniami, weryfikacją domeny lub limitem zidentyfikowany w szczegółach zdarzenia niepowodzenia.

Najbliższe 24 godziny

• Sprawdź, czy ta sama przyczyna zdarzenia niepowodzenia pojawia się w obu przepływach uwierzytelniania, czy tylko w jednym.

Najbliższe 7 dni

• Udokumentuj odpowiedź dla każdej przyczyny zdarzenia niepowodzenia zaobserwowanej u wdrożonego dostawcy.

Kontrole techniczne

Kryteria weryfikacji

• Oddzielne kontrolowane testy rejestracji i resetu hasła osiągają stan dostarczenia u dostawcy, zamiast zatrzymywać się na wysłaniu.
• Dwa przepływy testowe pozostają rozróżnialne w rekordach zdarzeń, więc nawrót problemu można wyizolować według przepływu.

Kryteria eskalacji

• Eskaluj do dostawcy e-mail, gdy zdarzenia opóźnienia dostarczenia utrzymują się bez użytecznego szczegółu tymczasowej przyczyny.
• Eskaluj do zespołu inżynieryjnego będącego właścicielem, gdy zdarzenia niepowodzenia identyfikują jako przyczynę poświadczenia, weryfikację domeny lub limit.

Zapobieganie

• Utrzymuj oddzielne kontrolowane testy rejestracji i resetu hasła, aby obie ścieżki uwierzytelniania można było sprawdzać niezależnie.

Wpływ na biznes

• Incydent może zakłócić potwierdzenie rejestracji, reset hasła lub oba te odrębne przepływy uwierzytelniania.

Uwagi dostawcy

• Nazwy sent, delivered, delivery-delayed i failed w tym runbooku to semantyka zdarzeń Resend; zmapuj równoważne stany dla innego dostawcy.

Otwarte pytania

• Dotknięta platforma, dostawca, środowisko i identyfikatory wiadomości nie są dostarczone; dokładna przyczyna główna nie może zostać określona na podstawie samego pytania.
• To, czy dotyczy to rejestracji, resetu hasła, czy obu, musi zostać zmierzone za pomocą oddzielnych kontrolowanych wyzwalaczy i śladów zdarzeń.
• Nazwy zdarzeń u dostawców i zachowanie ponowień różnią się; zmapuj udokumentowane stany Resend na wdrożonego dostawcę.

Pierwsze 15 minut

1. Ustal, czy projekt używa konektora Resend, czy zarządzanego e-maila Lovable Cloud.
2. W przypadku konektora Resend sprawdź klucz API, konfigurację nadawcy lub domeny, powiązanie projektu oraz odrzuconą lub zakończoną niepowodzeniem aktywność.
3. W przypadku Lovable Cloud potwierdź, że własna domena ma status Verified, a e-mail jest włączony dla projektu.

Teraz

• Przywróć poprawny klucz API Resend, konfigurację nadawcy lub domeny oraz powiązanie projektu, gdy testy konektora wykażą niezgodność.

Najbliższe 24 godziny

• Przywróć wysyłanie z własnej domeny Lovable Cloud dopiero po tym, jak domena uzyska status Verified, a e-mail zostanie włączony dla projektu.

Najbliższe 7 dni

• Udokumentuj oddzielne kontrole powiązania konektora i domeny Cloud, aby przyszłe incydenty były kierowane na właściwą ścieżkę.

Kontrole techniczne

Kryteria weryfikacji

• Nowy test konektora pojawia się na zamierzonym koncie Resend bez odrzuconej lub zakończonej niepowodzeniem aktywności.
• Test Lovable Cloud jest wysyłany dopiero po tym, jak własna domena pokaże status Verified, a e-mail w projekcie jest włączony.

Kryteria eskalacji

• Eskaluj powtarzalny błąd platformy lub brakujące obejście do wsparcia Lovable i korzystaj ze strony statusu Lovable, aby uzyskać aktualizacje dotyczące incydentów na całej platformie.

Zapobieganie

• Rejestruj, które projekty są powiązane z konektorem Resend w przestrzeni roboczej i traktuj odłączenie jako usunięcie dostępu do e-maila.
• Monitoruj weryfikację domeny Lovable Cloud i włączenie e-maila w projekcie jako oddzielne kontrole.

Wpływ na biznes

• Odłączony konektor Resend odbiera projektowi dostęp do tego połączenia e-mailowego.
• Poczta z własną domeną Lovable Cloud wymaga zarówno zweryfikowanej domeny, jak i włączonego e-maila dla projektu.

Uwagi dostawcy

• Zarządzany e-mail Lovable Cloud jest udokumentowany na poziomie 100 wiadomości na godzinę na przestrzeń roboczą; ten limit nie dotyczy oddzielnego konektora Resend.

Otwarte pytania

• Pytanie nie określa, czy aplikacja używa zarządzanego e-maila Lovable Cloud, czy oddzielnego konektora Resend; ich kontrole i logi się różnią.
• Nie dostarczono logów projektu, stanu konektora, statusu domeny, błędu HTTP, stanu limitu ani identyfikatora wiadomości dostawcy, więc dokładna przyczyna jest nieznana.
• Awarii specyficznej dla dzierżawcy (tenant) nie można przypisać do incydentu w całym Lovable bez jednoczesnych dowodów w postaci statusu.

Pierwsze 15 minut

1. Skoreluj znaczniki czasu akceptacji API, wysłania, opóźnienia dostarczenia i dostarczenia dla kontrolowanych żądań OTP.
2. Porównaj zmierzony czas przekazania ze skonfigurowanym czasem wygaśnięcia OTP w projekcie, zamiast zakładać domyślne ustawienie hostowane.

Teraz

• Użyj Send Email Auth Hook w Supabase, aby kolejkować e-maile uwierzytelniające, gdy skoki ruchu przyczyniają się do opóźnień.

Najbliższe 24 godziny

• Skonfiguruj kolejkę Send Email Auth Hook, aby wygładzić obserwowane skoki liczby e-maili uwierzytelniających.

Najbliższe 7 dni

• Rozważ kierowanie Send Email Auth Hook przez wiele usług wysyłkowych w celu zwiększenia niezawodności.

Kontrole techniczne

Kryteria weryfikacji

• Kontrolowane żądania osiągają zdarzenie dostarczenia przed skonfigurowanym czasem wygaśnięcia OTP w projekcie.
• Zmierzony interwał od wysłania do dostarczenia pozostaje widoczny dla każdego kontrolowanego żądania OTP.

Kryteria eskalacji

• Eskaluj do dostawcy, gdy zdarzenia opóźnienia dostarczenia utrzymują się, a szczegóły ich tymczasowej przyczyny nie wyjaśniają powrotu do normy.
• Eskaluj do inżynierii, gdy zdarzenia niepowodzenia identyfikują błędy odbiorcy, poświadczeń, weryfikacji domeny lub limitu.

Zapobieganie

• Utrzymuj skonfigurowany interwał żądań jako jawny, zamiast zakładać domyślne 60 sekund hostowane przez Supabase.
• Używaj zakolejkowanego Send Email Auth Hook i, w stosownych przypadkach, wielu usług wysyłkowych, aby wygładzać skoki ruchu i poprawiać niezawodność.

Wpływ na biznes

• OTP, które dociera po skonfigurowanym czasie wygaśnięcia, nie może zostać użyte w tym oknie ważności.

Uwagi dostawcy

• Jednogodzinny czas wygaśnięcia OTP i 60-sekundowy interwał żądań to domyślne ustawienia hostowane Supabase; konfiguracja projektu może się różnić.

Otwarte pytania

• Wdrożony dostawca uwierzytelniania, skonfigurowany czas życia OTP, znaczniki czasu kolejki, zdarzenia dostawcy, dostawca odbiorcy i obserwowany rozkład opóźnień nie zostały podane.
• Jednogodzinny czas wygaśnięcia i 60-sekundowe okno żądań to domyślne wartości Supabase, a nie uniwersalne wymagania OTP.
• Nierozstrzygnięte jest, czy opóźnienie występuje przed akceptacją przez dostawcę, podczas dostarczania przez dostawcę, czy po przekazaniu do serwera odbiorcy.

Pierwsze 15 minut

1. Potwierdź, czy brakujący strumień to weryfikacja logowania z noreply[at]salesforce.com, a nie reset hasła z support[at]salesforce.com.
2. Zażądaj Salesforce Email Log Files, aby ustalić, czy wiadomość weryfikacyjna została wysłana, czy zakończyła się niepowodzeniem.
3. Sprawdź Login History i Identity Verification History pod kątem wyzwania i miejsca docelowego, do którego Salesforce próbował wysłać wiadomość.

Teraz

• Gdy filtrowana jest tylko weryfikacja logowania, prześledź i dodaj noreply[at]salesforce.com do listy dozwolonych dla tego strumienia.

Najbliższe 24 godziny

• Użyj śledzenia Message-ID lub nadawcy, aby potwierdzić, że zmiana na liście dozwolonych wpływa na zamierzony strumień weryfikacji.

Najbliższe 7 dni

• Udokumentuj odrębnych nadawców Salesforce i limit pięciu żądań kodu weryfikacyjnego na godzinę w runbooku wsparcia.

Kontrole techniczne

Kryteria weryfikacji

• Salesforce Email Log Files pokazują, czy kontrolowana wiadomość weryfikacyjna została wysłana, czy zakończyła się niepowodzeniem.
• Jeśli log pokazuje dostarczenie do serwera odbiorcy, śledzenie po stronie odbiorcy identyfikuje późniejszą decyzję filtra.

Kryteria eskalacji

• Eskaluj do administratora poczty odbiorcy, gdy logi Salesforce pokazują dostarczenie do serwera odbiorcy, ale wiadomość jest nadal filtrowana.
• Eskaluj przypadek filtrowania specyficznego dla nadawcy, gdy śledzenie Message-ID i dodanie noreply[at]salesforce.com do listy dozwolonych nie przywracają strumienia weryfikacji logowania.

Zapobieganie

• Monitoruj strumień weryfikacji noreply[at]salesforce.com oddzielnie od strumienia resetu hasła support[at]salesforce.com.
• Zachowaj logi e-mail Salesforce i historię wyzwań, aby można było odróżnić przekazanie wiadomości od filtrowania przez odbiorcę.

Wpływ na biznes

• Filtrowanie strumienia weryfikacji logowania noreply[at]salesforce.com może uniemożliwić użytkownikom otrzymanie tej ścieżki weryfikacji, nawet jeśli maile z resetem hasła nie są dotknięte problemem.

Uwagi dostawcy

• Salesforce dokumentuje noreply[at]salesforce.com dla weryfikacji logowania, support[at]salesforce.com dla resetu hasła oraz limit pięciu żądań kodu na godzinę dla opisanego przepływu weryfikacji.

Otwarte pytania

• Salesforce Email Log Files, Login History, Identity Verification History, Message-ID, domena odbiorcy i werdykt filtra nie zostały podane.
• Adresy nadawców Salesforce i limity kodów są ograniczone do udokumentowanych przepływów i mogą się różnić w zależności od produktu lub metody weryfikacji.
• Bez wyniku przekazania przez Salesforce incydent nie może zostać jeszcze przypisany do wysyłki Salesforce ani do systemu pocztowego odbiorcy.

Pierwsze 15 minut

1. Dopasuj zdarzenie zamówienia do zdarzenia wysłania u dostawcy, a następnie sprawdź przekazanie do serwera odbiorcy (dostarczenie).
2. Sprawdź, czy odbiorca jest wykluczony (suppressed) po twardym odrzuceniu lub skardze spamowej.
3. Przed jakimkolwiek ponowieniem ustal, czy ważny klucz idempotencyjności może zapobiec zduplikowanemu żądaniu.

Teraz

• Zidentyfikuj i skoryguj oryginalną przyczynę twardego odrzucenia lub skargi przed zmianą wykluczonego odbiorcy.

Najbliższe 24 godziny

• Usuń wykluczenie dopiero po potwierdzeniu adresu i naprawieniu podstawowej przyczyny.

Najbliższe 7 dni

• Sprawdź, czy rozwiązani odbiorcy są ponownie wykluczani, co wskazuje, że pierwotna przyczyna nadal występuje.

Kontrole techniczne

Kryteria weryfikacji

• Kontrolowane potwierdzenie zamówienia osiąga stan dostarczenia u dostawcy, zamiast zatrzymywać się na wysłaniu.
• Adresy testowe dostawcy odtwarzają wyniki dostarczenia, odrzucenia, skargi i wykluczenia bez użycia fałszywych odbiorców.

Kryteria eskalacji

• Eskaluj do dostawcy, gdy wiadomość ma zdarzenie wysłania, ale nie ma wyjaśnialnego zdarzenia dostarczenia lub końcowego.
• Eskaluj do zespołu dostarczalności, gdy przyczyny wykluczenia nie można skorygować bez ryzyka kolejnego twardego odrzucenia lub skargi.

Zapobieganie

• Używaj klucza idempotencyjności Resend w ponawianych żądaniach potwierdzenia zamówienia w ramach jego 24-godzinnego okna przechowywania.
• Testuj ścieżki dostarczenia, odrzucenia, skargi i wykluczenia za pomocą udokumentowanych adresów testowych dostawcy.
• Wymagaj naprawienia pierwotnej przyczyny odrzucenia lub skargi przed usunięciem wykluczenia.

Wpływ na biznes

• Brakujące potwierdzenie zamówienia jeden-do-jednego zakłóca wiadomość transakcyjną wyzwalaną przez zakup klienta.

Uwagi dostawcy

• Stany wysłania i dostarczenia w Resend, regionalne wykluczenia, adresy testowe i 24-godzinne okno idempotencyjności to kontrole specyficzne dla dostawcy.

Otwarte pytania

• ID zdarzenia zamówienia, adres odbiorcy, ID wiadomości dostawcy, odpowiedź API, zdarzenia dostarczenia i stan wykluczenia nie zostały podane.
• Dokładny dostawca jest nieznany; fakty dotyczące Resend i Postmark opisują specyficzne dla dostawcy przykłady stanu i klasyfikacji.
• Przekazanie do serwera odbiorcy nie dowodzi widoczności w skrzynce odbiorczej ani przeczytania przez klienta.

Pierwsze 15 minut

1. Potwierdź, że adres odbiorcy jest wstępnie autoryzowany jako członek zespołu organizacji projektu, gdy używane jest domyślne SMTP.
2. Sprawdź, czy Supabase zwróciło HTTP 429 i czy ma zastosowanie limit wbudowanego dostawcy dla całego projektu.
3. Prześledź żądanie poza sukces API do zdarzeń wysłania i dostarczenia w dół potoku.

Teraz

• Zdecyduj, czy stagingowa ścieżka uwierzytelniania wymaga niezawodności niestandardowego SMTP zamiast domyślnego SMTP.

Najbliższe 24 godziny

• Skonfiguruj niestandardowe SMTP, gdy ścieżka e-maila uwierzytelniającego jest produkcyjna lub w inny sposób krytyczna.

Najbliższe 7 dni

• Utrzymuj krytyczne e-maile uwierzytelniające na ścieżce niestandardowego SMTP zalecanej przez Supabase.

Kontrole techniczne

Kryteria weryfikacji

• Kontrolowane żądanie OTP osiąga zdarzenie dostarczenia w dół potoku, a nie tylko stan wysłania lub sukcesu API.
• Krytyczna ścieżka używa skonfigurowanej usługi niestandardowego SMTP zamiast domyślnego SMTP Supabase.

Kryteria eskalacji

• Eskaluj do właściciela projektu, gdy krytyczna ścieżka uwierzytelniania nadal zależy od domyślnego SMTP typu "best-effort".
• Eskaluj konfigurację e-mail, gdy niestandardowe SMTP jest wymagane, ale jeszcze nieobecne dla krytycznego przepływu.

Zapobieganie

• Śledź limit dwóch wiadomości na godzinę wbudowanego dostawcy dla całego projektu wszędzie tam, gdzie pozostaje on włączony.
• Używaj niestandardowego SMTP do produkcyjnych i innych krytycznych e-maili uwierzytelniających Supabase.

Wpływ na biznes

• Przepływ stagingowy, który polega na domyślnym SMTP typu "best-effort", nie może używać odpowiedzi o sukcesie API jako gwarancji przekazania do serwera odbiorcy w dół potoku.

Uwagi dostawcy

• Domyślne SMTP Supabase ogranicza odbiorców do autoryzowanych adresów zespołu projektu, działa na zasadzie "best-effort" i jest przeznaczone wyłącznie do użytku nieprodukcyjnego.

Otwarte pytania

• API OTP i dostawca e-mail nie są zidentyfikowani; zachowania Supabase i Resend nie można zakładać dla innego stosu technologicznego.
• Autoryzacja zespołu projektu dla odbiorcy, bieżąca odpowiedź dotycząca limitu, konfiguracja SMTP i zdarzenia dostarczenia w dół potoku nie zostały podane.
• Sama odpowiedź o sukcesie API nie pozwala zidentyfikować, gdzie zatrzymał się potok e-mail w dół.

Pierwsze 15 minut

1. Oddziel udane żądania API od zdarzeń dostarczenia, odrzucenia, skargi i opóźnienia dla dotkniętego strumienia wiadomości.
2. Sprawdź, czy każde ponowienie przestrzegało kontraktu idempotencyjności wdrożonego dostawcy; dla Resend potwierdź, że ten sam klucz i ładunek zostały ponownie użyte w ciągu 24 godzin.

Teraz

• Dodaj obsługiwaną przez dostawcę idempotencyjność do powtarzających się żądań wysyłki.
• Deduplikuj zdarzenia webhooka SendGrid według sg_event_id, gdy jest obecny.

Najbliższe 24 godziny

• Ustaw maksymalny czas dostarczania Amazon SES dla poczty wrażliwej na czas na okres ważności w aplikacji.

Najbliższe 7 dni

• Oddziel wiadomości transakcyjne jeden-do-jednego od newsletterów, ogłoszeń i innych strumieni masowych, używając równoważnych kontroli wdrożonego dostawcy.

Kontrole techniczne

Kryteria weryfikacji

• Testowa wysyłka generuje wynik końcowego dostarczenia, odrzucenia, skargi lub opóźnienia, odrębny od akceptacji API.
• Monitorowanie raportuje zdarzenia końcowego dostarczenia, odrzucenia, skargi i opóźnienia dla strumienia transakcyjnego, zamiast liczyć akceptację API jako dostarczenie do klienta.

Kryteria eskalacji

• Eskaluj do ESP i inżynierii, gdy zaakceptowanym wysyłkom brakuje wyniku końcowego dostarczenia, odrzucenia, skargi lub opóźnienia od dostawcy.

Zapobieganie

• Używaj idempotentnych żądań wysyłki i deduplikuj wywołania zwrotne zdarzeń od dostawcy.
• Utrzymuj strumienie transakcyjne oddzielnie od poczty masowej i alertuj o wynikach końcowego dostarczenia, odrzucenia, skargi i opóźnienia.

Wpływ na biznes

• Wrażliwe na czas wiadomości, takie jak e-mail z jednorazowym hasłem, mogą dotrzeć poza użytecznym okresem ważności w aplikacji, chyba że okno dostarczania jest odpowiednio dostosowane.
• Traktowanie akceptacji API jako dostarczenia do klienta może ukryć odrzucenie, skargę, opóźnienie lub brakujące wyniki końcowego dostarczenia.

Uwagi dostawcy

• SendGrid ponawia POST Event Webhook po odpowiedzi innej niż 2xx w rosnących odstępach czasu przez maksymalnie 24 godziny.

Otwarte pytania

• Wdrożony ESP, jego kontrakt idempotencyjności, gwarancje dostarczania webhooków, stan wykluczenia i możliwości failover nie są dostępne.
• Biznesowe SLO, okna ważności tokenów, akceptowalne ryzyko duplikatów i zaobserwowane luki w zdarzeniach muszą zostać dostarczone przez właściciela SaaS.