Miért állítja le az AI-jegyzetelőd a felvételt a meeting kellős közepén

Július 2-án a GeekBye magától befejezett egy meetingfelvételt. Az adatbázissor mindent elmond: ended_reason = 'idle', 519 másodperc időtartam, 99 átiratbejegyzés — az utolsó két másodperccel azelőtt íródott, hogy az app úgy döntött, senki sincs ott.

A másik résztvevő épp egy magyarázat közepén járt. Az átirat utolsó sora szó szerint egy mondattöredék: "...executes it or turns it on or so—".

Nem ez volt az első eset. Előző este egy másik munkamenet ugyanígy ért véget. Két meeting, amelyet a saját megbízhatósági funkciónk ölt meg. Íme a diagnózis és a javítás, amely a GeekBye v2.0.9-ben jelent meg — plusz egy második, ijesztőbb bug, amelyet ugyanabban a kiadásban javítottunk.

Egy jó szándékú időzítő, amely csak téged hallott

A tétlenségi auto-bezárás jó okkal létezik. Az emberek éjszakára bekapcsolva felejtik a felvételt; egy nyitva hagyott meetingfül a végtelenségig csöpögteti a hangot. A GeekBye ezért figyeli az inaktivitást: 60 másodperc beszédaktivitás nélkül megjelenít egy kis "Still recording?" (magyarul: „még felveszel?”) kérdést, és 30 másodperccel később, ha nincs válasz, befejezi a munkamenetet — mindent elmentve, udvariasan.

A hiba egyetlen szóban rejlett: beszéd. Az aktivitásóra kizárólag a tartós mikrofonenergiát számolta. Ez tudatos tervezési döntés volt, és nem is buta: ha a nyers rendszerhang-energia számítana, egy lenémított, de zajos fül a végtelenségig életben tarthatna egy halott munkamenetet — ami pontosan az a hiba, amelynek megelőzésére a funkció létezik. A meetingeket, ahol többnyire hallgatsz, elvileg a meetingablak-felismerésnek kellett volna lefednie.

Csakhogy a meetingfelismerés nem lát minden meetinget. Böngészőfülek, szokatlan kliensek, egy prezentáció, amelyet épp nézel — észrevétlenek maradnak. És egy fel nem ismert meetingben, ahol 90 másodpercig hallgatsz — teljesen normális dolog, miközben valaki a Databricks-pipeline-ját magyarázza — a tétlenségi óra számára megkülönböztethetetlen vagy egy üres szobától.

Nézd meg a megölt munkamenet idővonalát: az utolsó átirat a mi mikrofonunkból 68 másodperccel a vége előtt érkezett. Utána 60 másodpercnyi beszéd a másik féltől (tökéletesen átírva, az óra által figyelmen kívül hagyva), az észrevétlen kérdés, a 30 másodperces visszaszámlálás, és a kivégzés — 2 másodperccel az ő utolsó szavai után.

A javítás: az átirat maga az életjel

A korrekció utólag már-már kínos: egy beérkező átirat a lehető legerősebb bizonyíték arra, hogy a munkamenet nem tétlen. Nem számít, ki beszélt. A beszédmodell épp szavakat ismert fel — az maga a meeting.

A v2.0.9 ezért minden beérkező átiratnál frissíti az aktivitásórát, bármelyik oldalról jön is. A nyers rendszerhang-energia továbbra sem számít: a zene, a várakoztatózene és a légkondi zúgása továbbra sem tehet halhatatlanná egy halott munkamenetet, a kemény felvételi limit pedig továbbra is mindent bebiztosít. Csak a felismert beszéd tart életben egy munkamenetet — és pontosan ez a helyes határvonal.

Egy code review-ból származó részlet, amelyet érdemes továbbadni: a javítás első verziója a beszélő-attribúciós útvonalon belül frissítette az órát — amelyet az átiratok egy része legitim módon kihagyhat. A review elkapta, hogy egy jövőbeli változtatás csendben visszahozhatná a bugot pontosan azoknál az átiratoknál, amelyek számítanak (a másik beszélőéinél). A frissítés most feltétel nélküli, minden elágazás előtt áll, és van egy teszt, amely elbukik, ha bárki elmozdítja.

Ugyanez a kiadás valami ijesztőbbet is javított

Miközben ezeket a javításokat teszteltük, a nehezebbik úton futottunk bele egy másik bugba: a felületi folyamat összeomlása az egész asztalt kattinthatatlanná tette.

A GeekBye overlay-e egy átlátszó, mindig legfelül lévő ablak, amely a képernyődet fedi. Alapból átkattintható; a felület kapcsolja interaktívra, amikor egy panelt használsz. Ezek a kapcsolások a felületi folyamatból érkeznek — így amikor az a folyamat nyitott panel mellett omlott össze, a láthatatlan ablak interaktív módban ragadt, mögötte élő UI nélkül. Az asztalodon minden kattintás egy halott, láthatatlan felületen landolt. Az egyetlen menekülőút az app kényszerített bezárása volt.

A v2.0.9 összeomlás-kezelője mostantól azonnal visszaállítja az átkattinthatóságot, és újratölti a felületet — percenként legfeljebb három újratöltéssel, hogy egy crash-loop ne pöröghessen a végtelenségig (a limit felett az app feladja az újratöltést, de az asztalod használható marad, és ez az, ami igazán számít). A code review ezt is élesítette: a helyreállítás kifejezetten az overlay-ablakra van szűkítve, mert ha az átkattinthatóságot válogatás nélkül alkalmaznánk egy összeomlott normál ablakra — mondjuk a frissítési párbeszédablakra —, az épp az ellenkező irányú kizárást hozta volna létre.

Ezt a javítást magad is ellenőrizheted, brutálisan: nyiss meg egy GeekBye-panelt, lődd ki a "GeekBye Helper (Renderer)" folyamatot az Activity Monitorban, és nézd, ahogy az app egy másodpercen belül visszaadja az asztalodat.

Mit tanultunk ebből a bugpárból

1. Minden proxy, amely az „itt van-e a felhasználó?” kérdést helyettesíti, valahol elbukik. A mikrofonenergia a hallgatóknál bukik el. Az ablakfelismerés a böngészőknél. A felismert átiratok... eddig még semminél, mert nem proxyk — hanem maga a termék.
2. Mindennek, amit a renderer vezérel, kell egy összeomlási forgatókönyv. Ha egy halott UI-folyamat OS-szintű állapotot hagyhat maga után (egérfogás, mindig-legfelül, tartalomvédelem), a fő folyamatnak kell birtokolnia a visszaállítást.
3. A saját legkeményebb felhasználódnak lenni bugvadász-stratégia. Mindkét bug valódi meetingekben talált el minket, mielőtt néhány ügyfélnél több észrevette volna. A hónapokkal korábban megfigyelhetőségi célból hozzáadott ended_reason oszlop tette a diagnózist adatbázis-lekérdezéssé találgatás helyett.

Mindkét javítás egy napon belül jutott el a diagnózistól az aláírt, notarizált kiadásig, mindegyiket átnézett PR vitte, regressziós tesztekkel. Ha GeekBye v2-n vagy, a v2.0.9 óta auto-update révén már meg is kaptad őket.

A kiadás történetének többi részéhez lásd a sorozat szomszédját: miért hallja félre az AI-átirat a szakkifejezéseket (v2.0.11), a megbízhatósági alapozást a miért áll le az AI-jegyzetelőd rossz Wi-Fi-n cikkben, és azt, hogyan marad az overlay láthatatlan képernyőmegosztás közben anélkül, hogy ellopná a kattintásaidat.