Який стан NetworkManager насправді отримав ваш сповіщувач?

Стан чотири породжує сповіщення в одному API і означає щось інше в іншому, а код не показує жодної різниці. Кожне значення стану в NetworkManager належить іменованому переліку, і переліки не сходяться в тому, що означає дане число. Тому копіювання цілого числа з робочого фрагмента в інший зворотний виклик — не перенесення поведінки, а збіг, що чекає на поломку. Спочатку знайдіть тип, і число стане читабельним.

Число без типу — це лише чутка

Тут важливі два переліки. Один описує активне з’єднання загалом: невідомо, активація, активне, деактивація, вимкнено. Другий описує саме VPN-з’єднання, і в ньому більше зупинок на шляху, зокрема підготовка, налаштування з’єднання, конфігурація IP і запит автентифікації, перш ніж щось активується. Їхня нумерація в обох випадках починається з нуля, а потім розходиться, тому значення, що означає «вимкнено» в загальному переліку, потрапляє кудись у середину послідовності VPN. Жоден заголовок не є помилковим; вони відповідають на різні питання.

Використовуйте символьну константу зі встановленого заголовка або прив’язки, а не літерал. Ім’я переживає перенумерацію; ціле число — ні.

Стежте за одним з’єднанням, а не за машиною

Почніть з UUID профілю, який вас цікавить, і об’єкта активного з’єднання, створеного цією активацією. Стан пристрою або стан іншого тунелю не є заміною, навіть коли обидва змінюються в той самий момент. Зберігайте ідентичність об’єкта разом із спостереженням, щоб пізніший звіт міг сказати, який профіль його породив. Машина має багато станів; сповіщення стосується одного з них.

Потім вирішіть, що має означати сповіщення. З’єднання, яке так і не дійшло до активації, — це збій налаштування, а сеанс, який був активним, а потім зник, — це втрата. Вони заслуговують на різні слова.

Скажіть, який перехід ви повідомляєте

Збережіть попередній стан і порівняйте його з новим, замість того щоб перевіряти нове значення ізольовано. Перехід у невдалий стан і перехід з активного стану — різні події, навіть коли обидва закінчуються нічим не під’єднаним. Запишіть поруч рядок причини, бо часто це єдина частина, на яку користувач може вплинути.

Навмисне від’єднання — не несправність. Якщо сповіщення не може відрізнити, воно навчить людей ігнорувати його.

Тримайте спостерігач живим

Повторне опитування не повинно піднімати ще одне попередження для стану, який не змінився. Це єдине правило прибирає більшу частину шуму, який створюють такі сповіщувачі.

Опрацюйте й випадок, коли менеджер перезапускається або спостережуваний об’єкт замінюється. Спостерігач, прив’язаний до застарілої ідентичності, замовкає саме в той момент, коли відбувається щось цікаве, а тиша виглядає як здоров’я. Знову виявіть поточний об’єкт після зміни присутності менеджера й запишіть, коли сталося повторне виявлення. Інакше журнал показує тунель, який просто перестав звітувати.

Доставте сповіщення туди, де перебуває користувач

Привілейований системний зворотний виклик не успадковує службу сповіщень сеансу робочого столу. Повідомлення, надіслане з обробника рівня root, може зникнути без помилки, що дає сповіщувач, який працює під час ручної перевірки і ніколи на практиці. Доставляйте в сеанс, якому належить робочий стіл, або дозвольте власному клієнту робочого столу підняти сповіщення.

Надавайте перевагу наявному сповіщенню клієнта, якщо воно вже покриває випадок, бо два сповіщувачі на одну подію — це проблема підтримки, а не надмірність. Зберігайте в записі підтримки час події, профіль і причину, а паролі й повні профілі тримайте поза ним. Пам’ятайте, що таке сповіщення: звіт про спостережуваний стан, а не механізм примусу, бо блокування трафіку за відсутності тунелю — окрема політика з власною реалізацією.