Który stan NetworkManager faktycznie otrzymał twój powiadamiacz?

Stan czwarty wywołuje powiadomienie w jednym API i oznacza coś innego w innym, a kod nie pokazuje żadnej różnicy. Każda wartość stanu w NetworkManager należy do nazwanego wyliczenia, a wyliczenia nie zgadzają się co do znaczenia danej liczby. Kopiowanie liczby całkowitej z działającego fragmentu do innego wywołania zwrotnego nie jest więc przeniesieniem zachowania; to zbieg okoliczności czekający na rozpad. Najpierw znajdź typ, a liczba stanie się czytelna.

Liczba bez typu to tylko pogłoska

Znaczenie mają tu dwa wyliczenia. Jedno opisuje aktywne połączenie ogólnie: nieznane, aktywujące, aktywne, dezaktywujące, dezaktywowane. Drugie opisuje konkretnie połączenie VPN i ma więcej przystanków po drodze, w tym przygotowanie, konfigurację połączenia, konfigurację IP oraz żądanie uwierzytelnienia, zanim cokolwiek zostanie aktywowane. Ich numeracja zaczyna się od zera w obu przypadkach, a potem się rozchodzi, więc wartość oznaczająca dezaktywowane w wyliczeniu ogólnym trafia gdzieś w środek sekwencji VPN. Żaden z nagłówków nie jest błędny; odpowiadają na różne pytania.

Użyj stałej symbolicznej z zainstalowanego nagłówka lub wiązania zamiast literału. Nazwa przetrwa przenumerowanie; liczba całkowita nie.

Obserwuj jedno połączenie, nie maszynę

Zacznij od UUID profilu, który cię interesuje, i od obiektu aktywnego połączenia utworzonego przez tę aktywację. Stan urządzenia albo stan innego tunelu nie jest zamiennikiem, nawet gdy oba zmieniają się w tej samej chwili. Zachowaj tożsamość obiektu razem z obserwacją, aby późniejszy raport mógł powiedzieć, który profil go wytworzył. Maszyna ma wiele stanów; powiadomienie dotyczy jednego z nich.

Potem zdecyduj, co powiadomienie ma znaczyć. Połączenie, które nigdy nie osiągnęło aktywacji, to błąd konfiguracji, a sesja, która była aktywna, a potem zniknęła, to strata. Te zasługują na różne słowa.

Powiedz, które przejście raportujesz

Zapisz poprzedni stan i porównaj go z nowym, zamiast testować nową wartość w izolacji. Przejście do stanu nieudanego i przejście z aktywnego stanu to różne zdarzenia, nawet gdy oba kończą się bez niczego podłączonego. Zapisz obok ciąg przyczyny, bo często jest to jedyna część, na którą użytkownik może zareagować.

Celowe rozłączenie nie jest awarią. Jeśli powiadomienie nie potrafi tego odróżnić, nauczy ludzi je ignorować.

Utrzymaj obserwatora przy życiu

Powtarzane odpytywanie nie może wywołać kolejnego alarmu dla stanu, który się nie zmienił. Ta jedna zasada usuwa większość szumu, który generują te powiadamiacze.

Obsłuż też przypadek, gdy menedżer się restartuje albo obserwowany obiekt zostaje zastąpiony. Obserwator przywiązany do nieaktualnej tożsamości milknie dokładnie w chwili, gdy dzieje się coś ciekawego, a cisza wygląda jak zdrowie. Odkryj ponownie bieżący obiekt po zmianie obecności menedżera i zapisz, kiedy nastąpiło ponowne odkrycie. Inaczej dziennik pokazuje tunel, który po prostu przestał raportować.

Dostarcz powiadomienie tam, gdzie jest użytkownik

Uprzywilejowane wywołanie zwrotne systemu nie dziedziczy usługi powiadomień sesji pulpitu. Wiadomość wysłana z procedury obsługi na poziomie root może zniknąć bez błędu, co daje powiadamiacz, który działa przy ręcznym testowaniu i nigdy w praktyce. Dostarczaj do sesji, która posiada pulpit, albo pozwól własnemu klientowi pulpitu wywołać powiadomienie.

Preferuj istniejące powiadomienie klienta, jeśli już obejmuje ten przypadek, bo dwa powiadamiacze dla jednego zdarzenia to problem wsparcia, a nie nadmiarowość. Zachowaj w rekordzie wsparcia czas zdarzenia, profil i przyczynę, a hasła i pełne profile pozostaw poza nim. Pamiętaj, czym jest powiadomienie: raportem o obserwowanym stanie, a nie mechanizmem egzekwowania, bo blokowanie ruchu przy braku tunelu to osobna polityka z własną implementacją.