Oto zdanie, które powoduje najdroższe błędy w automatyzacji LinkedIn: API zwróciło 200, więc post poszedł.
Niekoniecznie. 2xx z dowolnego API LinkedIn znaczy, że żądanie zostało przyjęte i przekazane dalej. Co LinkedIn z nim potem zrobi — nie pokaże nikomu, wstrzyma do przeglądu, cicho porzuci, pokaże i zdejmie dwadzieścia minut później — nie jest w tej odpowiedzi, a w kilku przypadkach nie jest w żadnej odpowiedzi.
Dlaczego ta przepaść istnieje
Między twoim kodem a widocznym postem są co najmniej dwa przeskoki, a drugi to platforma z własnym zdaniem o treściach automatycznych. Synchroniczny kod stanu nie może zdać sprawy z decyzji, która jeszcze nie zapadła. Nikt niczego nie ukrywa; informacja nie istnieje w chwili, gdy odpowiedź jest pisana.
Co robić zamiast zakładać
- Zapisz to, co wysłałeś, razem z odpowiedzią i znacznikiem czasu. Nie wartość logiczną: ciało.
- Odczytaj to z powrotem. Jeśli post ma znaczenie, pobierz go potem i zapisz, co wróciło.
- Traktuj liczbę wywołań i liczbę widocznych wyników jako dwie różne miary, bo nimi są.
- Nigdy nie pokazuj klientowi “opublikowano” na podstawie samego kodu stanu.
Wersja, która boli najbardziej
Przekroczony czas. Twoje żądanie nie zawiodło — po prostu przestałeś czekać na odpowiedź. Zapis mógł spokojnie dojść. Ponawianie to sposób, w jaki jedna wiadomość staje się dwiema, a drugą zauważa twój klient. Trzymaj identyfikator każdego zapisu, który zamierzasz wykonać, sprawdzaj przed ponowieniem i wolej odczytać świat, niż odtwarzać żądanie.
O co ludzie pytają
Czy agent SI zna tę różnicę?
Tylko jeśli mu się o niej powie. Agent SI, który dostaje 200, zwykle zgłosi post jako opublikowany. Wpisz regułę w jego instrukcje: zgłaszaj zapis jako przyjęty i odczytaj go z powrotem, zanim powiesz, że poszedł.
Jak pokój projektowy zgłasza zapis?
Jako odpowiedź agenta SI, w pokoju, gdzie każdy ją widzi. To dobry powód, żeby poprosić agenta o zacytowanie tego, co wysłał, i id, które dostał z powrotem.