Derfor stopper din AI-notetager med at optage midt i mødet

Den 2. juli afsluttede GeekBye en mødeoptagelse på egen hånd. Databaserækken siger det hele: ended_reason = 'idle', varighed 519 sekunder, 99 transskriptposter — den sidste skrevet to sekunder før, appen besluttede, at der ikke var nogen til stede.

Den anden deltager var midt i en forklaring. Transskriptets sidste linje er bogstaveligt talt et sætningsfragment: "...executes it or turns it on or so—".

Det var ikke første gang. Aftenen før endte en anden session på samme måde. To møder, dræbt af vores egen pålidelighedsfunktion. Her er diagnosen og fixet, der udkom i GeekBye v2.0.9 — plus en anden og mere skræmmende bug, vi fiksede i samme release.

En velment timer, der kun kunne høre dig

Idle-autolukningen findes af en god grund. Folk glemmer optagelser, der kører natten over; en efterladt mødefane bliver ved med at dryppe lyd i det uendelige. Så GeekBye holder øje med inaktivitet: efter 60 sekunder uden stemmeaktivitet viser den en lille "Still recording?" ("optager du stadig?")-prompt, og 30 sekunder senere, ubesvaret, afslutter den sessionen — gemmer alt, høfligt.

Fejlen lå i ét ord: stemme. Aktivitetsuret talte udelukkende vedvarende mikrofonenergi. Det var en bevidst designbeslutning, og ikke en dum en — at tælle rå systemlyd-energi ville lade en mutet-men-støjende fane holde en død session i live på ubestemt tid, hvilket er præcis den fejl, funktionen findes for at forhindre. Møder, hvor du mest lytter, skulle være dækket af mødevinduesdetektering.

Bortset fra at mødedetektering ikke kan se alle møder. Browserfaner, usædvanlige klienter, en præsentation du sidder og ser — uopdaget. Og i et uopdaget møde, hvor du lytter i 90 sekunder — en helt normal ting at gøre, mens nogen forklarer deres Databricks-pipeline — er du for idle-uret ikke til at skelne fra et tomt rum.

Se på tidslinjen for den dræbte session: det sidste transskript fra vores mikrofon kom 68 sekunder før afslutningen. Derefter 60 sekunder, hvor den anden person talte (transskriberet perfekt, ignoreret af uret), den ubemærkede prompt, nedtællingen på 30 sekunder og drabet — 2 sekunder efter vedkommendes sidste ord.

Fixet: et transskript er et livstegn

Rettelsen er næsten pinlig i bagklogskabens lys: et indkommende transskript er det stærkest mulige bevis på, at sessionen ikke er idle. Det er ligegyldigt, hvem der talte. Talemodellen har lige genkendt ord — det er mødet.

Så v2.0.9 stempler aktivitetsuret ved hvert transskript, der ankommer, fra begge sider. Rå systemlyd-energi tæller stadig ikke — musik, ventetoner og ventilationsbrum kan stadig ikke gøre en død session udødelig, og det hårde optagelsesloft er stadig bagstopper for det hele. Kun genkendt tale holder en session i live, hvilket er præcis den rigtige grænse.

Én detalje fra code review, der er værd at give videre: den første version af fixet stemplede uret inde i taler-tilskrivningsstien — som en delmængde af transskripter legitimt kan springe over. Reviewet fangede, at en fremtidig ændring stille kunne genindføre buggen for præcis de transskripter, der betyder noget (den anden talers). Stemplet er nu ubetinget, før enhver forgrening, med en test der fejler, hvis nogen flytter det.

Samme release fiksede noget mere skræmmende

Mens vi testede disse fixes, ramte vi en anden bug på den hårde måde: et crash i interface-processen efterlod hele skrivebordet uklikbart.

GeekByes overlay er et gennemsigtigt, altid-øverst vindue, der dækker din skærm. Det er klik-igennem som standard; interfacet slår det interaktivt til, når du bruger et panel. De skift kommer fra interface-processen — så da den proces crashede, mens et panel var åbent, blev det usynlige vindue stående i interaktiv tilstand uden noget levende UI bagved. Hvert eneste klik på dit skrivebord landede på en død, usynlig rude. Den eneste udvej var at tvangslukke appen.

v2.0.9's crash-handler gendanner nu klik-igennem med det samme og genindlæser interfacet — med et loft på tre genindlæsninger i minuttet, så et crash-loop ikke kan spinne i det uendelige (over loftet opgiver appen at genindlæse, men dit skrivebord forbliver brugbart, og det er den del, der betyder noget). Code review skærpede også denne: gendannelsen er afgrænset til selve overlay-vinduet, for at smøre klik-igennem ud over et crashet normalt vindue — for eksempel opdateringsdialogen — ville have skabt den modsatte lockout.

Du kan selv verificere fixet, på den brutale måde: åbn et GeekBye-panel, tvangsdræb processen "GeekBye Helper (Renderer)" i Aktivitetsovervågning, og se appen gendanne dit skrivebord inden for et sekund.

Hvad dette bug-par lærte os

1. Enhver proxy for "er brugeren her?" fejler et eller andet sted. Mikrofonenergi fejler for lyttere. Vinduesdetektering fejler for browsere. Genkendte transskripter fejler for... ikke noget, vi har fundet endnu, for de er ikke en proxy — de er selve produktet.
2. Alt, der drives fra rendereren, skal have en crash-historie. Hvis en død UI-proces kan efterlade tilstand på OS-niveau (musefangst, altid-øverst, indholdsbeskyttelse), skal main-processen eje nulstillingen.
3. At være sin egen tungeste bruger er en bug-jagtstrategi. Begge bugs ramte os i rigtige møder, før mere end en håndfuld kunder bemærkede noget. Kolonnen ended_reason, som vi havde tilføjet for observabilitetens skyld måneder tidligere, er det, der gjorde diagnosen til en databaseforespørgsel i stedet for et gæt.

Begge fixes gik fra diagnose til en udgivet, notariseret release inden for et døgn, hver båret af en reviewet PR med regressionstests. Kører du GeekBye v2, har du haft dem siden v2.0.9 via auto-opdatering.

For resten af denne releases historie, se serienaboen derfor hører AI-transskription tekniske termer forkert (v2.0.11), pålidelighedsfundamentet i hvorfor din AI-notetager stopper på dårligt wi-fi, og hvordan overlayet forbliver usynligt under skærmdeling uden at stjæle dine klik.