Därför slutar din AI-anteckningsapp spela in mitt i mötet

Den 2 juli avslutade GeekBye en mötesinspelning helt på egen hand. Databasraden säger allt: ended_reason = 'idle', längd 519 sekunder, 99 transkriptposter — den sista skriven två sekunder innan appen bestämde att ingen var där.

Den andra deltagaren var mitt i en förklaring. Transkriptets sista rad är bokstavligen ett meningsfragment: "...executes it or turns it on or so—".

Det var inte första gången. Kvällen innan avslutades en annan session på samma sätt. Två möten, avlivade av vår egen tillförlitlighetsfunktion. Här är diagnosen och fixen som skeppades i GeekBye v2.0.9 — plus en andra, läskigare bugg vi fixade i samma release.

En välmenande timer som bara kunde höra dig

Den automatiska idle-stängningen finns av ett gott skäl. Folk glömmer inspelningar igång över natten; en kvarlämnad mötesflik fortsätter droppa ljud i all evighet. Så GeekBye vakar över inaktivitet: efter 60 sekunder utan röstaktivitet visas en liten "Still recording?"-fråga ("spelar du fortfarande in?"), och 30 sekunder senare, obesvarad, avslutas sessionen — allt sparas, artigt.

Felet satt i ett enda ord: röst. Aktivitetsklockan räknade enbart ihållande mikrofonenergi. Det var ett medvetet designbeslut, och inget dumt sådant — att räkna rå systemljudsenergi skulle låta en mutad men brusig flik hålla en död session vid liv i all oändlighet, vilket är exakt det fel funktionen finns för att förhindra. Möten där du mest lyssnar skulle täckas av mötesfönsterdetekteringen.

Fast mötesdetekteringen kan inte se varje möte. Webbläsarflikar, ovanliga klienter, en presentation du tittar på — odetekterade. Och i ett odetekterat möte där du lyssnar i 90 sekunder — en fullständigt normal sak att göra medan någon förklarar sin Databricks-pipeline — är du, för idle-klockan, omöjlig att skilja från ett tomt rum.

Titta på tidslinjen för den avlivade sessionen: det sista transkriptet från vår mikrofon kom 68 sekunder före slutet. Sedan 60 sekunder där den andra personen pratar (perfekt transkriberat, ignorerat av klockan), den obemärkta frågan, 30-sekundersnedräkningen och avlivningen — 2 sekunder efter deras sista ord.

Fixen: ett transkript är ett livstecken

Rättelsen är nästan pinsam i efterhand: ett inkommande transkript är det starkast möjliga beviset på att sessionen inte är inaktiv. Det spelar ingen roll vem som pratade. Talmodellen har just känt igen ord — det är mötet.

Så v2.0.9 stämplar aktivitetsklockan vid varje transkript som anländer, från vilken sida som helst. Rå systemljudsenergi räknas fortfarande inte — musik, kötoner och fläktbrus kan fortfarande inte göra en död session odödlig, och det hårda inspelningstaket finns kvar som sista spärr bakom allt. Bara igenkänt tal håller en session vid liv, vilket är precis rätt gräns.

En detalj från kodgranskningen värd att skicka vidare: den första versionen av fixen stämplade klockan inne i talarattribueringsvägen — som en delmängd av transkripten legitimt kan hoppa över. Granskningen fångade att en framtida ändring tyst kunde återinföra buggen för exakt de transkript som spelar roll (den andra talarens). Stämpeln är nu ovillkorlig, före all förgrening, med ett test som fallerar om någon flyttar den.

Samma release fixade något läskigare

Medan vi testade de här fixarna träffade vi en annan bugg den hårda vägen: en krasch i gränssnittsprocessen lämnade hela skrivbordet oklickbart.

GeekByes overlay är ett transparent, alltid-överst-fönster som täcker din skärm. Det är klickgenomsläppligt som standard; gränssnittet växlar det till interaktivt när du använder en panel. De växlingarna kommer från gränssnittsprocessen — så när den processen kraschade medan en panel var öppen blev det osynliga fönstret kvar i interaktivt läge utan något levande UI bakom sig. Varje klick på ditt skrivbord landade på en död, osynlig ruta. Enda utvägen var att tvångsavsluta appen.

v2.0.9:s kraschhanterare återställer nu klickgenomsläppet omedelbart och laddar om gränssnittet — med ett tak på tre omladdningar per minut så att en kraschloop inte kan snurra för evigt (över taket ger appen upp omladdningarna, men ditt skrivbord förblir användbart, vilket är den del som spelar roll). Kodgranskningen vässade den här också: återhämtningen är avgränsad till just overlay-fönstret, eftersom att svepande applicera klickgenomsläpp på ett kraschat vanligt fönster — säg uppdateringsdialogen — hade skapat den omvända utlåsningen.

Du kan verifiera fixen själv, brutalt: öppna en GeekBye-panel, tvångsdöda processen "GeekBye Helper (Renderer)" i Aktivitetskontroll och se appen återställa ditt skrivbord inom en sekund.

Vad det här buggparet lärde oss

1. Varje proxy för "är användaren kvar?" fallerar någonstans. Mikrofonenergi fallerar för lyssnare. Fönsterdetektering fallerar för webbläsare. Igenkända transkript fallerar för... ingenting vi hittat än, för de är ingen proxy — de är själva produkten.
2. Allt som drivs från renderern behöver en kraschberättelse. Om en död UI-process kan lämna OS-nivåtillstånd efter sig (musfångst, alltid-överst, innehållsskydd) måste huvudprocessen äga återställningen.
3. Att vara sin egen tyngsta användare är en buggjaktsstrategi. Båda buggarna drabbade oss i riktiga möten innan mer än en handfull kunder märkte något. Kolumnen ended_reason som vi lagt till för observerbarhet månader tidigare är det som gjorde diagnosen till en databasfråga i stället för en gissning.

Båda fixarna gick från diagnos till en skeppad, notariserad release inom ett dygn, var och en buren av en granskad PR med regressionstester. Kör du GeekBye v2 har du haft dem sedan v2.0.9 via automatisk uppdatering.

För resten av den här releasens historia, se seriegrannen därför hör AI-transkribering fel på tekniska termer (v2.0.11), tillförlitlighetsgrunden i varför din AI-anteckningsapp stannar på dåligt wifi och hur overlayn förblir osynlig under skärmdelning utan att stjäla dina klick.