TL;DR
- Les exécutions de visibilité planifiées se lançaient même machine hors ligne, si bien qu'un portable fermé signifiait une exécution qui échouait sur chaque requête.
- L'application fait désormais une vraie vérification de connectivité avant qu'une exécution planifiée ne démarre, parce que le système d'exploitation annonce « en ligne » dès que le portable se réveille, avant que la connexion ne fonctionne.
- Si la connexion meurt en cours d'exécution, celle-ci s'arrête et le planning réessaie une fois la machine de retour en ligne.
- Les requêtes échouées sont tenues à l'écart de vos résultats, si bien que seules les vraies réponses comptent.
- Aussi cette semaine : une exécution de visibilité terminée peut être confiée directement au chat de Moose pour une conversation plus longue sur les résultats, et les personnalisations du lecteur audio sont désormais enregistrées.
Planifiée pour échouer
Hi, Moose vérifie votre visibilité IA selon un planning : il interroge les assistants IA qu'utilisent vos clients sur votre secteur et note si vous apparaissez. C'est l'application de bureau qui pose les questions, depuis votre machine.
C'est là que vivait le bug. Le planning savait quand une exécution était due. Il ne savait pas si le portable pouvait atteindre internet. Fermez le capot, prenez un train, rouvrez-le quelque part avec un wifi qui n'a pas encore statué sur votre cas, et une exécution due se lançait quand même, posait chacune de ses questions à une connexion morte et échouait sur la moindre requête. Tout ce travail, rien à montrer, et un désordre que le tableau de bord devait nettoyer.
Une tâche planifiée qui ne lève pas le nez de sa liste, c'est une panne très parlante. C'est aussi une panne qui se répare.
Les barres de wifi ne sont pas internet
Le correctif évident, c'est « vérifie d'abord si tu es en ligne », et voici ce qui a rendu la chose intéressante : le système d'exploitation est un optimiste. Dès qu'un portable sort de veille, l'interface wifi est active et le système annonce connecté, pendant que le DNS et le routage cherchent encore leurs chaussures. Une exécution lancée dans cet intervalle échoue exactement comme avant, sous l'œil d'une icône wifi bien verte.
Alors l'application a cessé de demander son avis au système et s'est mise à vérifier elle-même. Avant qu'une exécution planifiée ne commence, elle envoie une vraie requête à deux points de connectivité bien connus, du même genre que ceux que votre portable utilise pour détecter les pages d'accueil des cafés, et retient la première réponse qui arrive. Aucune réponse ni de l'un ni de l'autre, pas d'exécution pour l'instant. Le planning attend simplement, et l'exécution se lance une fois la connexion réelle.
S'arrêter, puis réessayer
Les connexions meurent aussi en pleine exécution. L'exécution s'en aperçoit désormais : si deux requêtes d'affilée reviennent bredouilles, elle vérifie la connexion avant de dépenser du temps sur le reste. Une seule vérification peut mettre plusieurs minutes à renoncer face à une connexion morte, et une exécution en compte beaucoup, donc s'en apercevoir tôt compte.
S'il s'avère que la machine est hors ligne, l'exécution s'arrête, met de côté sa pile partielle d'échecs et rouvre la fenêtre du planning du jour. Une fois de retour en ligne, elle se lance une fois et fait le travail proprement. Et les requêtes échouées restent de toute façon à l'écart de vos résultats, si bien que seules les vraies réponses comptent.
Une exécution à qui parler
Aussi cette semaine : quand une exécution de visibilité se termine et que vous voulez creuser, vous pouvez la confier au chat de Moose pour pousser l'analyse. Les résultats l'accompagnent, et comme c'est l'application elle-même qui a rédigé ce premier message, le chat se met directement au travail. D'un graphique à une conversation sur le graphique, en une étape.
Et une petite chose qui améliorera discrètement le mardi de quelqu'un : si vous personnalisez le lecteur audio intégré de la fonction Listen, vos réglages sont désormais enregistrés. Réglez-le une fois, gardez-le.
FAQ
Quel était le bug des exécutions de visibilité planifiées ?
Le planning se déclenchait, que la machine puisse atteindre internet ou non. Sur un portable fermé ou tout juste réveillé, l'exécution démarrait, échouait sur chaque requête et n'avait rien de réel à montrer.
Comment l'application vérifie-t-elle maintenant qu'elle est en ligne ?
Elle envoie une vraie requête à deux points de connectivité bien connus avant qu'une exécution planifiée ne démarre. L'indicateur de connexion du système d'exploitation ne suffit pas, parce qu'il annonce connecté dès que le portable se réveille, avant que la connexion ne fonctionne.
Que se passe-t-il si la connexion tombe en pleine exécution ?
L'exécution s'arrête au lieu de dérouler le reste de ses vérifications contre une connexion morte. Le planning se rouvre, et l'exécution se lance une fois quand la machine est de retour en ligne.
Les requêtes échouées affectent-elles mes résultats de visibilité ?
Non. Une requête restée sans réponse est signalée comme indisponible et tenue à l'écart de vos résultats, si bien que seules les vraies réponses comptent.
Celui qui est sous le bureau pendant tout ça.