Operacja jest idempotentna, gdy wykonana dwa razy zostawia świat taki, jaki zostawiła po jednym razie. Usunięcie pliku jest idempotentne. Wysłanie wiadomości nie jest, i w tej asymetrii mieszka większość błędów z podwójnymi wiadomościami.
Gdzie naprawdę jest potrzebna
- W obsłudze webhooków, bo dostawa jest co najmniej raz, a ponowienie jest normalne.
- We wszystkim, co ponawiasz po przekroczeniu czasu, bo przekroczony czas nie mówi, czy zapis doszedł.
- We wszystkim, co kolejka może dostarczyć ponownie, czyli w każdej kolejce.
Jak ją uzyskać tanio
Prowadź tabelę identyfikatorów, na które już zareagowałeś, i wstawiaj do niej z więzem unikalności, zanim wykonasz pracę. Jeśli wstawienie się nie uda, ktoś już to obsłużył. To cała technika; nie potrzebuje żadnej biblioteki i przeżywa restart w środku, którego wersja w pamięci nie przeżywa.
Wstawiaj przed, nie po. Wstawianie po zostawia okno między zrobieniem rzeczy a zapisaniem, że się ją zrobiło, a awaria w tym oknie to dokładnie przypadek, który tabela miała zasłonić.
Czego użyć jako identyfikatora
Tego, jak nadawca nazywa zdarzenie, jeśli daje ci nazwę. Jeśli nie daje, zbuduj klucz z pól, które czynią zdarzenie tym zdarzeniem — konto, rozmowa i wiadomość, dajmy na to — i policz z nich skrót. Klucz wyprowadzony ze znacznika czasu nie jest kluczem: ponowienie ma inny.
Idempotentność to nie odsiewanie duplikatów w interfejsie. Zanim duplikat trafi na ekran, drugą wiadomość już wysłałeś. Sprawdzenie należy na sam początek obsługi, zanim cokolwiek wyjdzie.
O co ludzie pytają
Czy agenci SI zwiększają ryzyko duplikatów?
Mogą. Agent SI poproszony dwa razy może wysłać dwa razy, a ten, który ponawia po przekroczeniu czasu, może nie wiedzieć, że pierwsza próba się udała. Daj mu w instrukcjach regułę — odczytaj rozmowę przed ponownym wysłaniem — i niech człowiek nadal zatwierdza wysyłki.
Czy przycisk „Zastosuj” w pokoju projektowym jest idempotentny?
Propozycja w pokoju wykonuje się tylko raz. Ponowne naciśnięcie „Zastosuj” niczego nie zmienia.