Ochrona przed podwójną dostawą

Ochrona przed podwójną dostawą

Skopiuj stronę

Włącz wykrywanie zduplikowanych webhooków: podaj nagłówek z identyfikatorem zdarzenia, a powtórzenia z 24 godzin nie uruchomią ponownie Shopify Flow.

Większość systemów ponawia próbę wysłania webhooka, gdy nie otrzymają szybkiej odpowiedzi. Jeśli pierwsza próba faktycznie dotarła, Państwa przepływ pracy w Shopify Flow zostanie uruchomiony dwukrotnie w związku z jednym zdarzeniem - spowoduje to wysłanie drugiego e-maila, utworzenie zduplikowanego tagu lub powtórzenie notatki do zamówienia.

Funkcja ochrony przed zduplikowanymi dostawami zapobiega takiej sytuacji. Jest ona domyślnie wyłączona dla każdego webhooka.

Jak to działa

Jeśli Państwa system wysyłkowy zawiera unikalny identyfikator dla każdego zdarzenia, proszę podać nazwę nagłówka, w którym znajduje się ten identyfikator, w sekcji Ustawienia zaawansowane → Wykrywanie zduplikowanych dostaw.

Zachowanie
Pierwsze żądanie o podanym identyfikatorze Przetworzono w standardowy sposób, uruchamia się Shopify Flow
Proszę powtórzyć w ciągu 24 godzin 200 OK z duplicate: true - nie zostało przesłane do Shopify Flow
Inny identyfikator Przetworzono w zwykły sposób
Proszę o przesłanie zapytania bez tego nagłówka Przetworzono w zwykły sposób
Pole pozostało puste Każde przetworzone zgłoszenie - nic się nie zmienia

Typowe nazwy nagłówków: Event-Id, Idempotency-Key, X-Request-Id. Podczas porównywania nie uwzględnia się wielkości liter.

bash
# Same Event-Id twice - the second is accepted but not re-sent to Flow
curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -H "Event-Id: evt_12345" \
  -d '{"orderId":"1001"}'

Dlaczego funkcja repeat nadal zwraca wartość 200?

Odpowiedź inna niż 2xx właśnie utrudnia nadawcy ponowną próbę. Odpowiedź 200 sygnalizuje, że zdarzenie zostało pomyślnie przetworzone, więc nadawca zaprzestaje dalszych prób - natomiast parametr duplicate: true w treści odpowiedzi pozwala odróżnić te dwa wyniki w przypadku rejestrowania odpowiedzi.

Gdzie pojawiają się duplikaty

Ukryty duplikat:

  • nie tworzy wpisu w historii wywołań, więc nie jest wliczane do Państwa pakietu
  • pojawia się w oknie Live Request Inspector podczas edycji webhooka, oznaczony jako pominięty duplikat

To połączenie jest zamierzone: Państwa historia połączeń i limit pozostają nienaruszone, ale połączenie nigdy nie sprawia wrażenia, jakby po cichu zniknęło.

Wybór odpowiedniego nagłówka

Identyfikator musi pozostawać niezmienny podczas ponownej próby i być unikalny dla każdego zdarzenia - na tym polega cały mechanizm.

Dopuszczalne: identyfikator zdarzenia lub klucz idempotencji wygenerowany jednorazowo przez nadawcę w momencie wystąpienia zdarzenia.

Nieprawidłowe i odrzucane w momencie zapisywania: nagłówki kontrolowane przez serwer proxy, takie jak X-Forwarded-For, CF-* lub X-Signature. Ich wartości zmieniają się w zależności od żądania lub przeskoku, więc nigdy nie pasowałyby do powtórzenia - powodując cichą awarię zamiast wyraźnego błędu.

W przypadku krótkotrwałej niedostępności magazynu danych po deduplikacji

Dostawa jest przetwarzana, a nie odrzucana. Powtórne uruchomienie przepływu pracy stanowi znacznie mniejszy problem niż utracone zdarzenie, dlatego funkcja ta działa zgodnie z założeniami w trybie „fail-open”.