Derfor slutter AI-notattakeren din å ta opp midt i møtet

Den 2. juli avsluttet GeekBye et møteopptak på egen hånd. Databaseraden sier alt: ended_reason = 'idle', varighet 519 sekunder, 99 transkriptoppføringer — den siste skrevet to sekunder før appen bestemte at ingen var der.

Den andre deltakeren var midt i en forklaring. Den siste linjen i transkriptet er bokstavelig talt et setningsfragment: "...executes it or turns it on or so—".

Det var ikke første gang. Kvelden før ble en annen økt avsluttet på samme måte. To møter, drept av vår egen pålitelighetsfunksjon. Her er diagnosen og fiksen som ble sendt ut i GeekBye v2.0.9 — pluss en annen, skumlere bug vi fikset i samme utgivelse.

En velment timer som bare kunne høre deg

Inaktivitets-autolukkingen finnes av en god grunn. Folk glemmer opptak som går natten over; en møtefane som blir stående åpen, fortsetter å dryppe lyd i det uendelige. Så GeekBye ser etter inaktivitet: etter 60 sekunder uten stemmeaktivitet viser den en liten "Still recording?"-melding ("tar du fortsatt opp?"), og 30 sekunder senere, ubesvart, avslutter den økten — lagrer alt, høflig.

Feilen lå i ett ord: stemme. Aktivitetsklokken telte kun vedvarende mikrofonenergi. Det var en bevisst designbeslutning, og ikke en dum en — å telle rå systemlyd-energi ville latt en dempet, men støyende fane holde en død økt i live på ubestemt tid, som er nøyaktig den feilen funksjonen finnes for å hindre. Møter der du stort sett lytter, skulle vært dekket av møtevindu-deteksjon.

Bortsett fra at møtedeteksjon ikke kan se alle møter. Nettleserfaner, uvanlige klienter, en presentasjon du ser på — uoppdaget. Og i et uoppdaget møte der du lytter i 90 sekunder — noe helt normalt å gjøre mens noen forklarer Databricks-pipelinen sin — er du, for inaktivitetsklokken, umulig å skille fra et tomt rom.

Se på tidslinjen for den drepte økten: det siste transkriptet fra vår mikrofon kom 68 sekunder før slutten. Så 60 sekunder med den andre personen som snakket (perfekt transkribert, ignorert av klokken), den ubemerkede meldingen, 30-sekunders nedtellingen, og drapet — 2 sekunder etter vedkommendes siste ord.

Fiksen: et transkript er bevis på liv

Rettelsen er nesten pinlig i etterpåklokskapens lys: et innkommende transkript er det sterkest mulige beviset på at økten ikke er inaktiv. Det spiller ingen rolle hvem som snakket. Talemodellen gjenkjente nettopp ord — det er møtet.

Så v2.0.9 stempler aktivitetsklokken ved hvert transkript som ankommer, fra begge sider. Rå systemlyd-energi teller fortsatt ikke — musikk, ventetoner og ventilasjonsdur kan fortsatt ikke udødeliggjøre en død økt, og det harde opptakstaket er fortsatt siste skanse for alt. Bare gjenkjent tale holder en økt i live, som er nøyaktig riktig grense.

Én detalj fra kodegjennomgangen som er verdt å gi videre: den første versjonen av fiksen stemplet klokken inne i taler-attribusjonsstien — som en delmengde av transkriptene legitimt kan hoppe over. Gjennomgangen fanget opp at en fremtidig endring stille kunne gjeninnføre buggen for nøyaktig de transkriptene som betyr noe (den andre talerens). Stempelet er nå ubetinget, før all forgrening, med en test som feiler hvis noen flytter det.

Samme utgivelse fikset noe skumlere

Mens vi testet disse fiksene, traff vi en annen bug på den harde måten: et krasj i grensesnittprosessen etterlot hele skrivebordet uklikkbart.

GeekByes overlay er et gjennomsiktig alltid-øverst-vindu som dekker skjermen din. Det er klikk-gjennom som standard; grensesnittet slår det over til interaktivt når du bruker et panel. De vekslingene kommer fra grensesnittprosessen — så da den prosessen krasjet mens et panel var åpent, ble det usynlige vinduet stående i interaktiv modus uten noe levende UI bak seg. Hvert klikk på skrivebordet ditt landet på en død, usynlig rute. Den eneste utveien var å tvangsavslutte appen.

Krasjhåndtereren i v2.0.9 gjenoppretter nå klikk-gjennom umiddelbart og laster grensesnittet på nytt — med et tak på tre omlastinger per minutt, slik at en krasjloop ikke kan spinne evig (forbi taket gir appen opp å laste på nytt, men skrivebordet ditt forblir brukbart, som er delen som betyr noe). Kodegjennomgangen skjerpet også denne: gjenopprettingen er avgrenset til selve overlay-vinduet, fordi å påføre klikk-gjennom over hele linja på et krasjet vanlig vindu — si oppdateringsdialogen — ville skapt den motsatte utestengelsen.

Du kan verifisere denne fiksen selv, brutalt: åpne et GeekBye-panel, tvangsdrep "GeekBye Helper (Renderer)"-prosessen i Aktivitetsmonitor, og se appen gjenopprette skrivebordet ditt innen et sekund.

Hva dette bug-paret lærte oss

1. Hver proxy for "er brukeren her?" feiler et sted. Mikrofonenergi feiler for lyttere. Vindusdeteksjon feiler for nettlesere. Gjenkjente transkripter feiler for... ingenting vi har funnet ennå, fordi de ikke er en proxy — de er selve produktet.
2. Alt som styres fra rendereren trenger en krasjhistorie. Hvis en død UI-prosess kan etterlate tilstand på OS-nivå (musefangst, alltid-øverst, innholdsbeskyttelse), må hovedprosessen eie tilbakestillingen.
3. Å være din egen tyngste bruker er en bug-jaktstrategi. Begge buggene traff oss i ekte møter før mer enn en håndfull kunder merket noe. ended_reason-kolonnen vi hadde lagt til for observerbarhet måneder tidligere, er det som gjorde diagnosen til en databasespørring i stedet for en gjetning.

Begge fiksene gikk fra diagnose til en utsendt, notarisert utgivelse innen et døgn, hver båret av en gjennomgått PR med regresjonstester. Er du på GeekBye v2, har du hatt dem siden v2.0.9 via auto-oppdatering.

For resten av historien om denne utgivelsen, se serienaboen derfor hører AI-transkripsjon tekniske termer feil (v2.0.11), pålitelighetsgrunnlaget i derfor stopper AI-notattakeren din på dårlig wifi, og hvordan overlayet forblir usynlig under skjermdeling uten å stjele klikkene dine.