Qual estado do NetworkManager o seu notificador realmente recebeu?

O estado quatro dispara uma notificação numa API e significa outra coisa noutra, e o código não mostra diferença alguma. Cada valor de estado no NetworkManager pertence a uma enumeração nomeada, e as enumerações não concordam sobre o que significa um dado número. Copiar um inteiro de um trecho que funciona para outro callback não é, portanto, uma transferência de comportamento; é uma coincidência à espera de quebrar. Encontre primeiro o tipo, e o número torna-se legível.

Um número sem tipo é apenas um rumor

Aqui importam duas enumerações. Uma descreve uma ligação ativa em geral: desconhecido, a ativar, ativo, a desativar, desativado. A outra descreve especificamente uma ligação VPN, e tem mais paragens pelo caminho, incluindo a preparação, a configuração da ligação, a configuração de IP e um pedido de autenticação antes de algo ser ativado. A numeração de ambas começa em zero nos dois casos e depois diverge, pelo que o valor que significa desativado na enumeração geral cai algures a meio da sequência VPN. Nenhum dos cabeçalhos está errado; respondem a perguntas diferentes.

Use a constante simbólica do cabeçalho ou binding instalado em vez de um literal. O nome sobrevive a uma renumeração; o inteiro não.

Observe uma ligação, não a máquina

Comece pelo UUID do perfil que lhe interessa e pelo objeto de ligação ativa criado por essa ativação. O estado de um dispositivo, ou o estado de outro túnel, não é um substituto, mesmo quando ambos mudam no mesmo instante. Mantenha a identidade do objeto junto da observação, para que um relatório posterior possa dizer que perfil o produziu. A máquina tem muitos estados; o aviso diz respeito a um deles.

Depois decida o que o aviso deve significar. Uma ligação que nunca chegou à ativação é uma falha de configuração, e uma sessão que estava ativa e depois desapareceu é uma perda. Estas merecem palavras diferentes.

Diga que transição está a reportar

Guarde o estado anterior e compare-o com o novo, em vez de testar o novo valor isoladamente. Uma transição para um estado falhado e uma transição fora de um estado ativado são eventos diferentes mesmo quando ambas terminam sem nada ligado. Registre a cadeia de motivo ao lado, porque muitas vezes é a única parte sobre a qual um utilizador pode agir.

Uma desconexão intencional não é uma avaria. Se o aviso não conseguir distinguir, ensinará as pessoas a ignorá-lo.

Mantenha o observador vivo

A interrogação repetida não deve gerar outro alerta para um estado que não mudou. Essa única regra remove a maior parte do ruído que estes notificadores geram.

Trate também o caso em que o gestor reinicia ou o objeto observado é substituído. Um observador ligado a uma identidade obsoleta cala-se exatamente no momento em que acontece algo interessante, e o silêncio parece saúde. Redescubra o objeto atual após uma mudança na presença do gestor, e registre quando ocorreu a redescoberta. Caso contrário, o registo mostra um túnel que simplesmente deixou de reportar.

Entregue o aviso onde o utilizador está

Um callback de sistema privilegiado não herda o serviço de notificações de uma sessão de ambiente de trabalho. Uma mensagem enviada de um manipulador ao nível de root pode desaparecer sem erro, o que produz um notificador que funciona quando testado à mão e nunca na prática. Entregue na sessão que possui o ambiente de trabalho, ou deixe o próprio cliente do ambiente de trabalho levantar o aviso.

Prefira a notificação existente do cliente se já cobre o caso, pois dois notificadores para um evento são um problema de suporte e não uma redundância. Mantenha a hora do evento, o perfil e o motivo no registo de suporte, e deixe de fora as palavras-passe e os perfis completos. Lembre-se do que é o aviso: um relatório de um estado observado, não um mecanismo de aplicação, porque bloquear o tráfego enquanto o túnel está ausente é uma política separada com a sua própria implementação.