Pourquoi votre notetaker IA arrête d'enregistrer en pleine réunion
Notre propre application a mis fin à deux de nos réunions alors que l'autre partie était au milieu d'une phrase. La piste forensique a mené à un minuteur d'inactivité bien intentionné qui ne pouvait entendre que vous — et à un second bug capable de verrouiller tout votre bureau. Les deux corrigés dans GeekBye v2.0.9.
Le 2 juillet, GeekBye a mis fin de lui-même à l'enregistrement d'une réunion. La ligne en base de données dit tout : ended_reason = 'idle', durée 519 secondes, 99 entrées de transcription — la dernière écrite deux secondes avant que l'application ne décide qu'il n'y avait personne.
L'autre participant était au milieu d'une explication. La dernière ligne de la transcription est littéralement un fragment de phrase : "...executes it or turns it on or so—".
Ce n'était pas la première fois. La veille au soir, une autre session s'était terminée de la même façon. Deux réunions, tuées par notre propre fonctionnalité de fiabilité. Voici le diagnostic et le correctif livré dans GeekBye v2.0.9 — plus un second bug, plus effrayant, corrigé dans la même version.
Un minuteur bien intentionné qui ne pouvait entendre que vous
La fermeture automatique pour inactivité existe pour une bonne raison. On oublie des enregistrements qui tournent toute la nuit ; un onglet de réunion resté ouvert continue de laisser filer de l'audio indéfiniment. GeekBye surveille donc l'inactivité : après 60 secondes sans activité vocale, il affiche une petite invite "Still recording?" (« Toujours en train d'enregistrer ? »), et 30 secondes plus tard, sans réponse, il met fin à la session — en sauvegardant tout, poliment.
Le défaut tenait à un mot : vocale. L'horloge d'activité ne comptait que l'énergie soutenue du microphone. C'était une décision de conception délibérée, et pas une bêtise — compter l'énergie brute de l'audio système permettrait à un onglet muet mais bruyant de maintenir indéfiniment en vie une session morte, exactement la défaillance que cette fonctionnalité doit empêcher. Les réunions où vous écoutez surtout étaient censées être couvertes par la détection des fenêtres de réunion.
Sauf que la détection de réunion ne peut pas voir toutes les réunions. Onglets de navigateur, clients inhabituels, une présentation que vous regardez — non détectés. Et dans une réunion non détectée où vous écoutez pendant 90 secondes — une chose parfaitement normale pendant que quelqu'un explique son pipeline Databricks — vous êtes, pour l'horloge d'inactivité, indiscernable d'une pièce vide.
Regardez la chronologie de la session tuée : la dernière transcription venue de notre micro est arrivée 68 secondes avant la fin. Puis 60 secondes de l'autre personne qui parle (transcrites parfaitement, ignorées par l'horloge), l'invite passée inaperçue, le compte à rebours de 30 secondes, et la coupure — 2 secondes après ses derniers mots.
Le correctif : une transcription est une preuve de vie
La correction est presque gênante avec le recul : une transcription entrante est la preuve la plus forte possible que la session n'est pas inactive. Peu importe qui a parlé. Le modèle vocal vient de reconnaître des mots — c'est ça, la réunion.
La v2.0.9 horodate donc l'horloge d'activité à chaque transcription qui arrive, quel que soit le côté. L'énergie brute de l'audio système ne compte toujours pas — la musique, les tonalités d'attente et le ronron de la climatisation ne peuvent toujours pas immortaliser une session morte, et le plafond dur d'enregistrement continue de tout sécuriser en dernier recours. Seule la parole reconnue maintient une session en vie, ce qui est précisément la bonne frontière.
Un détail issu de la revue de code qui mérite d'être transmis : la première version du correctif horodatait l'horloge à l'intérieur du chemin d'attribution du locuteur — qu'un sous-ensemble de transcriptions peut légitimement sauter. La revue a repéré qu'un changement futur pouvait réintroduire silencieusement le bug pour exactement les transcriptions qui comptent (celles de l'autre locuteur). L'horodatage est désormais inconditionnel, avant tout embranchement, avec un test qui échoue si quelqu'un le déplace.
La même version a corrigé quelque chose de plus effrayant
En testant ces correctifs, nous avons rencontré un autre bug à la dure : un crash du processus d'interface a laissé le bureau entier insensible aux clics.
L'overlay de GeekBye est une fenêtre transparente, toujours au premier plan, qui couvre votre écran. Par défaut, elle laisse passer les clics ; l'interface la rend interactive quand vous utilisez un panneau. Ces bascules viennent du processus d'interface — alors quand ce processus a crashé pendant qu'un panneau était ouvert, la fenêtre invisible est restée en mode interactif sans aucune UI vivante derrière. Chaque clic sur votre bureau atterrissait sur un panneau mort et invisible. La seule issue était de forcer la fermeture de l'application.
Le gestionnaire de crash de la v2.0.9 restaure désormais immédiatement le passage des clics et recharge l'interface — avec un plafond de trois rechargements par minute pour qu'une boucle de crash ne puisse pas tourner indéfiniment (au-delà du plafond, l'application renonce à recharger, mais votre bureau reste utilisable, et c'est ça qui compte). La revue de code a aussi affûté celui-ci : la récupération est limitée spécifiquement à la fenêtre d'overlay, parce qu'appliquer aveuglément le passage des clics à une fenêtre normale crashée — disons, la boîte de dialogue de mise à jour — aurait créé le verrouillage inverse.
Vous pouvez vérifier ce correctif vous-même, brutalement : ouvrez un panneau GeekBye, forcez l'arrêt du processus "GeekBye Helper (Renderer)" dans le Moniteur d'activité, et regardez l'application vous rendre votre bureau en moins d'une seconde.
Ce que cette paire de bugs nous a appris
- Chaque proxy de « l'utilisateur est-il là ? » échoue quelque part. L'énergie du micro échoue pour ceux qui écoutent. La détection de fenêtres échoue pour les navigateurs. Les transcriptions reconnues échouent pour... rien que nous ayons trouvé jusqu'ici, parce qu'elles ne sont pas un proxy — elles sont le produit lui-même.
- Tout ce qui est piloté par le renderer a besoin d'une histoire de crash. Si un processus d'UI mort peut laisser derrière lui de l'état au niveau de l'OS (capture de la souris, toujours au premier plan, protection du contenu), le processus principal doit posséder la remise à zéro.
- Être son propre utilisateur le plus intensif est une stratégie de chasse aux bugs. Les deux bugs nous ont frappés dans de vraies réunions avant que plus d'une poignée de clients ne les remarque. La colonne
ended_reasonajoutée des mois plus tôt pour l'observabilité est ce qui a fait du diagnostic une requête en base de données plutôt qu'une supposition.
Les deux correctifs sont passés du diagnostic à une version publiée et notarisée en moins d'un jour, chacun porté par une PR revue avec des tests de régression. Si vous êtes sur GeekBye v2, vous les avez depuis la v2.0.9 via la mise à jour automatique.
Pour le reste de l'histoire de cette version, voyez le voisin de la série pourquoi la transcription IA écorche les termes techniques (v2.0.11), les fondations de fiabilité dans pourquoi votre notetaker IA s'arrête sur un mauvais Wi-Fi, et comment l'overlay reste invisible pendant le partage d'écran sans voler vos clics.
