Кое NetworkManager-состојба всушност ја доби вашиот известувач?

Состојба четири активира известување на едно API и значи нешто друго на друго, а кодот не покажува никаква разлика. Секоја вредност на состојба во NetworkManager припаѓа на именувано набројување, а набројувањата не се согласуваат што значи даден број. Затоа копирањето цел број од работен фрагмент во различен callback не е пренос на однесување; тоа е случајност што чека да се скрши. Најпрво пронајдете го типот и бројот станува читлив.

Број без тип е само гласина

Овде се важни две набројувања. Едното опишува активна врска воопшто: непознато, активирање, активно, деактивирање, деактивирано. Другото опишува конкретно VPN врска и има повеќе застанувања на патот, вклучително подготовка, поставување на врската, IP конфигурација и барање за автентикација пред нешто да се активира. Нивното нумерирање започнува од нула во двата случаи и потоа се разидува, па вредноста што значи деактивирано во општото набројување завршува некаде во средината на VPN низата. Ниту едно заглавие не е погрешно; тие одговараат на различни прашања.

Користете симболична константа од инсталираното заглавие или врзување наместо литерал. Името преживува пренумерирање; целиот број не.

Набљудувајте една врска, не машината

Започнете од UUID на профилот што ве интересира и од објектот на активната врска што го создаде тоа активирање. Состојба на уред или состојба на друг тунел не е замена, дури и кога двете се менуваат во истиот момент. Задржете го идентитетот на објектот заедно со набљудувањето, за подоцнежен извештај да може да каже кој профил го создал. Машината има многу состојби; известувањето е за една од нив.

Потоа одлучете што треба да значи известувањето. Врска што никогаш не стигнала до активирање е неуспех во поставувањето, а сесија што била активна и потоа исчезнала е загуба. Овие заслужуваат различни зборови.

Кажете кој премин го известувате

Зачувајте ја претходната состојба и споредете ја со новата, наместо да ја тестирате новата вредност изолирано. Преминот во неуспешна состојба и преминот од активна состојба се различни настани, дури и кога двата завршуваат без ништо поврзано. Запишете ја низата со причина до него, зашто често тоа е единствениот дел на кој корисникот може да дејствува.

Намерното исклучување не е дефект. Ако известувањето не може да ја препознае разликата, ќе ги научи луѓето да го игнорираат.

Одржете го набљудувачот жив

Повторното анкетирање не смее да предизвика уште едно предупредување за состојба што не се променила. Тоа единствено правило го отстранува најголемиот дел од шумот што го создаваат овие известувачи.

Обработете го и случајот кога менаџерот се рестартира или набљудуваниот објект се заменува. Набљудувач врзан за застарена идентичност замолчува токму во моментот кога се случува нешто интересно, а тишината изгледа како здравје. Откријте го тековниот објект повторно по промена во присуството на менаџерот и запишете кога се случило повторното откривање. Инаку дневникот покажува тунел што едноставно престанал да известува.

Доставете го известувањето таму каде што е корисникот

Привилегиран системски callback не наследува услуга за известување на сесија на работна површина. Порака испратена од ракувач на ниво на root може да исчезне без грешка, што создава известувач што работи при рачно тестирање и никогаш во практика. Доставете во сесијата што ја поседува работната површина, или оставете сопствениот клиент на работната површина да го подигне известувањето.

Дајте предност на постоечкото известување на клиентот ако веќе го покрива случајот, зашто два известувачи за еден настан се проблем за поддршка, а не вишок. Задржете го времето на настанот, профилот и причината во записот за поддршка, а лозинките и целосните профили оставете ги надвор. Запомнете што е известувањето: извештај за набљудувана состојба, а не механизам за спроведување, зашто блокирањето сообраќај додека тунелот отсуствува е одделна политика со сопствена реализација.