Hvilken NetworkManager-tilstand fik din notifier egentlig?

Tilstand fire udløser en underretning på én API og betyder noget andet på en anden, og koden viser slet ingen forskel. Hver tilstandsværdi i NetworkManager hører til en navngivet optælling, og optællingerne er ikke enige om, hvad et givet tal betyder. At kopiere et heltal fra et fungerende uddrag til et andet callback er derfor ikke en overførsel af adfærd; det er et tilfælde, der venter på at gå i stykker. Find først typen, så bliver tallet læsbart.

Et tal uden en type er et rygte

To optællinger betyder noget her. Den ene beskriver en aktiv forbindelse generelt: ukendt, aktiverende, aktiveret, deaktiverende, deaktiveret. Den anden beskriver specifikt en VPN-forbindelse, og den har flere stop undervejs, herunder forberedelse, opsætning af forbindelsen, IP-konfiguration og en godkendelsesanmodning, før noget aktiveres. Deres nummerering starter ved nul i begge tilfælde og løber derefter fra hinanden, så den værdi, der betyder deaktiveret i den generelle optælling, lander et sted midt i VPN-sekvensen. Ingen af overskrifterne er forkerte; de besvarer forskellige spørgsmål.

Brug den symbolske konstant fra den installerede header eller binding i stedet for et literalt tal. Navnet overlever en omnummerering; heltallet gør ikke.

Hold øje med én forbindelse, ikke maskinen

Start fra den profil-UUID, du interesserer dig for, og det aktive forbindelsesobjekt, som den aktivering oprettede. En enhedstilstand eller en anden tunnels tilstand er ikke en erstatning, selv når begge ændrer sig i samme øjeblik. Behold objektets identitet sammen med observationen, så en senere rapport kan sige, hvilken profil der frembragte den. Maskinen har mange tilstande; underretningen handler om én af dem.

Beslut derefter, hvad underretningen skal betyde. En forbindelse, der aldrig nåede aktivering, er en opsætningsfejl, og en session, der var aktiv og derefter forsvandt, er et tab. De fortjener forskellige ord.

Sig, hvilken overgang du rapporterer

Gem den forrige tilstand og sammenlign den med den nye, i stedet for at teste den nye værdi isoleret. En overgang til en fejlet tilstand og en overgang ud af en aktiveret tilstand er forskellige hændelser, selv når begge ender med intet forbundet. Notér årsagsstrengen ved siden af, fordi den ofte er den eneste del, en bruger kan handle på.

En bevidst afbrydelse er ikke en fejl. Hvis underretningen ikke kan se forskellen, vil den lære folk at ignorere den.

Hold observatøren i live

Gentagen afstemning må ikke rejse endnu en advarsel for en tilstand, der ikke er ændret. Den ene regel fjerner det meste af den støj, disse notifiers skaber.

Håndtér også det tilfælde, hvor manageren genstarter, eller det observerede objekt udskiftes. En overvåger bundet til en forældet identitet går i stå præcis i det øjeblik, noget interessant sker, og stilhed ser ud som sundhed. Genopdag det aktuelle objekt efter en ændring i managerens tilstedeværelse, og notér, hvornår genopdagelsen skete. Ellers viser loggen en tunnel, der simpelthen holdt op med at rapportere.

Lever underretningen, hvor brugeren er

Et privilegeret system-callback arver ikke en skrivebordssessions underretningstjeneste. En besked sendt fra en handler på root-niveau kan forsvinde uden fejl, hvilket giver en notifier, der virker, når man tester den i hånden, og aldrig i praksis. Lever i den session, der ejer skrivebordet, eller lad skrivebordets egen klient rejse underretningen.

Foretræk klientens eksisterende underretning, hvis den allerede dækker tilfældet, da to notifiers for én hændelse er et supportproblem snarere end redundans. Behold hændelsestiden, profilen og årsagen i supportnotatet, og lad adgangskoder og fulde profiler være uden for det. Husk, hvad underretningen er: en rapport om en observeret tilstand, ikke en håndhævelsesmekanisme, fordi blokering af trafik, mens tunnelen mangler, er en separat politik med sin egen implementering.