Quel état de NetworkManager votre notificateur a-t-il réellement reçu ?

L’état quatre déclenche une notification sur une API et signifie autre chose sur une autre, et le code ne montre aucune différence. Chaque valeur d’état dans NetworkManager appartient à une énumération nommée, et les énumérations ne s’accordent pas sur ce que signifie un nombre donné. Copier un entier d’un extrait qui fonctionne vers un autre rappel n’est donc pas un transfert de comportement ; c’est une coïncidence qui attend de se briser. Trouvez d’abord le type, et le nombre devient lisible.

Un nombre sans type n’est qu’une rumeur

Deux énumérations comptent ici. L’une décrit une connexion active en général : inconnu, activation, activé, désactivation, désactivé. L’autre décrit spécifiquement une connexion VPN, et elle comporte plus d’étapes en chemin, notamment la préparation, la configuration de la connexion, la configuration IP et une demande d’authentification avant que quoi que ce soit soit activé. Leur numérotation commence à zéro dans les deux cas puis diverge, si bien que la valeur qui signifie désactivé dans l’énumération générale atterrit quelque part au milieu de la séquence VPN. Aucun des deux en-têtes n’est faux ; ils répondent à des questions différentes.

Utilisez la constante symbolique de l’en-tête ou de la liaison installée plutôt qu’un littéral. Le nom survit à une renumérotation ; l’entier non.

Surveillez une connexion, pas la machine

Partez de l’UUID du profil qui vous intéresse et de l’objet de connexion active créé par cette activation. L’état d’un appareil, ou l’état d’un autre tunnel, n’est pas un substitut, même lorsque les deux changent au même moment. Conservez l’identité de l’objet avec l’observation, afin qu’un rapport ultérieur puisse dire quel profil l’a produit. La machine a beaucoup d’états ; la notification concerne l’un d’eux.

Décidez ensuite ce que la notification doit signifier. Une connexion qui n’a jamais atteint l’activation est un échec de configuration, et une session qui était active puis a disparu est une perte. Celles-ci méritent des mots différents.

Dites quelle transition vous signalez

Stockez l’état précédent et comparez-le au nouveau, au lieu de tester la nouvelle valeur isolément. Une transition vers un état en échec et une transition hors d’un état activé sont des événements différents même lorsque les deux finissent sans rien de connecté. Notez la chaîne de raison à côté, car c’est souvent la seule partie sur laquelle un utilisateur peut agir.

Une déconnexion intentionnelle n’est pas une panne. Si la notification ne peut pas faire la différence, elle apprendra aux gens à l’ignorer.

Gardez l’observateur en vie

L’interrogation répétée ne doit pas déclencher une autre alerte pour un état qui n’a pas changé. Cette règle unique élimine la majeure partie du bruit que ces notificateurs génèrent.

Gérez aussi le cas où le gestionnaire redémarre ou l’objet observé est remplacé. Un observateur lié à une identité périmée se tait exactement au moment où quelque chose d’intéressant se produit, et le silence ressemble à la santé. Redécouvrez l’objet actuel après un changement de présence du gestionnaire, et notez quand la redécouverte a eu lieu. Sinon, le journal montre un tunnel qui a simplement cessé de signaler.

Livrez la notification là où se trouve l’utilisateur

Un rappel système privilégié n’hérite pas du service de notification d’une session de bureau. Un message envoyé depuis un gestionnaire au niveau root peut disparaître sans erreur, ce qui produit un notificateur qui fonctionne lorsqu’on le teste à la main et jamais en pratique. Livrez dans la session qui possède le bureau, ou laissez le propre client du bureau déclencher la notification.

Préférez la notification existante du client si elle couvre déjà le cas, car deux notificateurs pour un événement sont un problème de support plutôt qu’une redondance. Conservez l’heure de l’événement, le profil et la raison dans le dossier de support, et laissez les mots de passe et les profils complets en dehors. Rappelez-vous ce qu’est la notification : un rapport d’un état observé, pas un mécanisme d’application, car bloquer le trafic en l’absence du tunnel est une politique distincte avec sa propre implémentation.