Vilket NetworkManager-tillstånd fick din aviserare egentligen?

Tillstånd fyra utlöser en avisering på ett API och betyder något annat på ett annat, och koden visar ingen skillnad alls. Varje tillståndsvärde i NetworkManager tillhör en namngiven uppräkning, och uppräkningarna är inte överens om vad ett givet tal betyder. Att kopiera ett heltal från en fungerande snutt till en annan återanrop är därför inte en överföring av beteende; det är ett sammanträffande som väntar på att gå sönder. Hitta typen först, så blir talet läsbart.

Ett tal utan typ är bara ett rykte

Två uppräkningar spelar roll här. Den ena beskriver en aktiv anslutning i allmänhet: okänd, aktiverande, aktiverad, inaktiverande, inaktiverad. Den andra beskriver specifikt en VPN-anslutning, och den har fler stopp på vägen, bland annat förberedelse, konfiguration av anslutningen, IP-konfiguration och en autentiseringsbegäran innan något aktiveras. Deras numrering börjar på noll i båda fallen och går sedan isär, så värdet som betyder inaktiverad i den allmänna uppräkningen hamnar någonstans mitt i VPN-sekvensen. Ingen av rubrikerna är fel; de svarar på olika frågor.

Använd den symboliska konstanten från den installerade rubriken eller bindningen i stället för en literal. Namnet överlever en omnumrering; heltalet gör det inte.

Håll koll på en anslutning, inte maskinen

Börja med profil-UUID:n du bryr dig om och det aktiva anslutningsobjektet som aktiveringen skapade. Ett enhetstillstånd, eller tillståndet för en annan tunnel, är ingen ersättning, även när båda ändras i samma ögonblick. Behåll objektets identitet tillsammans med observationen, så att en senare rapport kan säga vilken profil som producerade den. Maskinen har många tillstånd; aviseringen handlar om ett av dem.

Bestäm sedan vad aviseringen ska betyda. En anslutning som aldrig nådde aktivering är ett konfigurationsfel, och en session som var aktiv och sedan försvann är en förlust. De förtjänar olika ord.

Säg vilken övergång du rapporterar

Spara det föregående tillståndet och jämför det med det nya, i stället för att testa det nya värdet isolerat. En övergång till ett misslyckat tillstånd och en övergång ur ett aktiverat tillstånd är olika händelser även när båda slutar med ingenting anslutet. Anteckna orsakssträngen bredvid, eftersom den ofta är den enda delen en användare kan agera på.

En avsiktlig frånkoppling är inte ett fel. Om aviseringen inte kan skilja på det kommer den att lära folk att ignorera den.

Håll observatören vid liv

Upprepad avfrågning får inte utlösa ännu en varning för ett tillstånd som inte har ändrats. Den enda regeln tar bort det mesta av bruset som dessa aviserare skapar.

Hantera också fallet där hanteraren startar om eller det observerade objektet byts ut. En övervakare bunden till en inaktuell identitet tystnar precis i det ögonblick något intressant händer, och tystnad ser ut som hälsa. Återupptäck det aktuella objektet efter en förändring i hanterarens närvaro, och anteckna när återupptäckten skedde. Annars visar loggen en tunnel som helt enkelt slutade rapportera.

Leverera aviseringen där användaren är

Ett privilegierat systemåteranrop ärver inte en skrivbordssessions aviseringstjänst. Ett meddelande som skickas från en hanterare på root-nivå kan försvinna utan fel, vilket ger en aviserare som fungerar när den testas för hand och aldrig i praktiken. Leverera in i sessionen som äger skrivbordet, eller låt skrivbordets egen klient resa aviseringen.

Föredra klientens befintliga avisering om den redan täcker fallet, eftersom två aviserare för en händelse är ett supportproblem snarare än redundans. Behåll händelsetiden, profilen och orsaken i supportposten, och håll lösenord och fullständiga profiler utanför den. Kom ihåg vad aviseringen är: en rapport om ett observerat tillstånd, inte en genomdrivandemekanism, eftersom att blockera trafik medan tunneln saknas är en separat policy med egen implementering.