Jak uniknąć wysłania tego samego SMS dwa razy?

Połączenie może zostać zerwane po tym, jak Bird zaakceptuje SMS, ale zanim twoja aplikacja otrzyma odpowiedź. Ponowna próba z nowym kluczem może spowodować drugie wysłanie, ponieważ Bird traktuje ją jako osobne żądanie.

Jak działa klucz?

Ustaw nagłówek Idempotency-Key dla każdego zamierzonego wysłania SMS i używaj go ponownie, gdy ponawiasz identyczne żądanie. Gwarancja akceptacji dokładnie raz oznacza, że pasujące ponowne próby w ciągu trzech godzin muszą prowadzić do tego samego zaakceptowanego wysłania, nawet jeśli odpowiedź na nie została utracona.

Na przykład potwierdzenie zamówienia zachowuje ten sam klucz po przekroczeniu limitu czasu i przy ponownej próbie. Potwierdzenie innego zamówienia dostaje inny klucz.

Odtworzone odpowiedzi zawierają Idempotency-Replay: true, co pozwala twoim logom odróżnić odtworzenie od nowo przetworzonego żądania.

Klucze SMS są przypisane do twojego obszaru roboczego. Bird przechowuje zakończone odpowiedzi przez trzy godziny zgodnie ze swoim kontraktem idempotentności. Po tym oknie ten sam klucz może wykonać nowe żądanie, ponieważ jego rekord odtwarzania wygasł. Ponowna próba dzień później wymaga więc ustalenia wyniku pierwotnej operacji przed kolejnym wysłaniem.

Co oznaczają odpowiedzi o błędach?

Kod błędu rozróżnia zmienione żądanie, niedokończone żądanie i niedostępną ochronę.

• 409 z E01005 IdempotencyKeyReuse: ten sam klucz został użyty dla innego żądania. Napraw przypisanie klucza przed ponowną próbą, ponieważ ten klucz należy do oryginalnego żądania. Bird porównuje metodę, endpoint, ścieżkę i parametry zapytania oraz surową treść żądania. Nawet zmiana białych znaków w JSON sprawia, że żądanie jest inne.
• 409 z E01004 RequestInProgress: równoległe żądanie z tym samym kluczem jeszcze się nie zakończyło. Poczekaj chwilę i spróbuj ponownie z tym samym kluczem i żądaniem, aby oryginalne żądanie mogło się zakończyć.
• 503 z E01033 IdempotencyUnavailable: ochrona była niedostępna przed wykonaniem, więc ta próba nie została wykonana. Spróbuj ponownie z backoffem, używając tego samego klucza i żądania. Ta odpowiedź nie ustala wyniku wcześniejszej próby.
• Inne odpowiedzi 5xx lub przekroczenia limitu czasu: spróbuj ponownie z backoffem, używając tego samego klucza i żądania. Gwarancja akceptacji dokładnie raz obejmuje te ponowne próby w ciągu trzech godzin. Przestań, gdy wyczerpiesz limit ponownych prób.

Nagłówek idempotentności zachowuje tożsamość żądania we wszystkich tych ponownych próbach.

Czy klucz gwarantuje brak duplikatów?

Gwarancja to akceptacja dokładnie raz dla identycznych żądań z tym samym kluczem w tym samym obszarze roboczym w ciągu trzech godzin. Te ponowne próby muszą prowadzić do jednego zaakceptowanego wysłania, także po utracie odpowiedzi. Sprawdź status wiadomości, aby potwierdzić doręczenie.

Po upływie trzygodzinnego okna retencji pierwotny klucz może identyfikować nową operację. Jeśli wynik pierwotnej operacji jest nieznany, porównaj zapisy dotyczące tego wyniku przed ponownym wysłaniem.

Prowadź rejestr zdarzeń i wysyłek w swojej aplikacji, aby móc porównać zapisy dotyczące niepewnego wyniku przed ponownym wysłaniem. Dołącz numer zamówienia lub referencji do wiadomości, żeby odbiorca mógł rozpoznać, którego zdarzenia dotyczy.

A co z wiadomością, którą telefon wyświetla dwa razy?

Klucz idempotentności kontroluje ponowne próby API; nie kontroluje tego, jak telefon odbiorcy wyświetla wiadomość. Sam zrzut ekranu nie ustala, skąd pochodzi duplikat.

Porównaj pełny log wysyłek aplikacji z rekordami wiadomości Bird. Wiele zaakceptowanych identyfikatorów wiadomości może potwierdzić wielokrotne wysłanie. Znalezienie tylko jednego identyfikatora w niekompletnym logu nie dowodzi, że duplikat powstał dalej w łańcuchu. Podaj odpowiednie identyfikatory, numer docelowy i znaczniki czasu, prosząc wsparcie o zbadanie sprawy.

Co powinienem zrobić?

1. Przypisz jeden klucz do każdego zamierzonego wysłania SMS i używaj identycznego żądania przy ponownych próbach.
2. Ponawiaj z backoffem żądania zakończone błędami sieciowymi, przekroczeniem limitu czasu i odpowiedziami 5xx, zachowując klucz i identyczne żądanie w ciągu trzech godzin.
3. Napraw konflikty ze zmienionymi żądaniami i opóźnij ponowne próby, gdy oryginalne żądanie wciąż trwa.
4. Traktuj wyczerpane lub wygasłe ponowne próby jako nierozstrzygnięte, dopóki nie porównasz zapisów dotyczących ich wyniku, zanim zdecydujesz, czy kolejne wysłanie jest właściwe.