De ce notetaker-ul tău AI oprește înregistrarea în mijlocul ședinței
Propria noastră aplicație ne-a încheiat două ședințe în timp ce cealaltă parte era în mijlocul unei fraze. Pista criminalistică a dus la un timer de inactivitate bine intenționat care nu putea auzi pe nimeni în afară de tine — și la un al doilea bug care îți putea bloca întregul desktop. Ambele rezolvate în GeekBye v2.0.9.
Pe 2 iulie, GeekBye a încheiat singur o înregistrare de ședință. Rândul din baza de date spune totul: ended_reason = 'idle', durată 519 secunde, 99 de intrări de transcript — ultima scrisă cu 2 secunde înainte ca aplicația să decidă că nu mai e nimeni acolo.
Celălalt participant era în mijlocul unei explicații. Ultima linie a transcriptului e literalmente un fragment de propoziție: "...executes it or turns it on or so—".
Nu era prima dată. Cu o seară înainte, o altă sesiune se încheiase la fel. Două ședințe, omorâte de propria noastră funcție de fiabilitate. Iată diagnosticul și fixul livrat în GeekBye v2.0.9 — plus un al doilea bug, mai înfricoșător, rezolvat în același release.
Un timer bine intenționat care te putea auzi doar pe tine
Auto-închiderea la inactivitate există dintr-un motiv bun. Oamenii uită înregistrări pornite peste noapte; un tab de meeting lăsat deschis picură audio la nesfârșit. Așa că GeekBye urmărește inactivitatea: după 60 de secunde fără activitate vocală afișează un mic prompt "Still recording?" (în română: „mai înregistrezi?"), iar 30 de secunde mai târziu, rămas fără răspuns, încheie sesiunea — salvând totul, politicos.
Defectul stătea într-un singur cuvânt: vocală. Ceasul de activitate număra doar energia susținută a microfonului. A fost o decizie de design deliberată, și nu una prostească — dacă ar fi numărat energia brută din audio-ul de sistem, un tab pe mut dar zgomotos ar fi putut ține în viață la nesfârșit o sesiune moartă, exact eșecul pe care funcția există să-l prevină. Ședințele în care mai mult asculți trebuiau acoperite de detecția ferestrelor de meeting.
Doar că detecția de meeting nu poate vedea orice ședință. Tab-uri de browser, clienți neobișnuiți, o prezentare la care te uiți — nedetectate. Iar într-o ședință nedetectată, în care asculți timp de 90 de secunde — un lucru complet normal cât timp cineva îți explică pipeline-ul lui de Databricks — ești, pentru ceasul de inactivitate, imposibil de deosebit de o cameră goală.
Uită-te la cronologia sesiunii omorâte: ultimul transcript de la microfonul nostru a venit cu 68 de secunde înainte de final. Apoi 60 de secunde în care cealaltă persoană a vorbit (transcrise perfect, ignorate de ceas), promptul neobservat, numărătoarea inversă de 30 de secunde și lovitura — la 2 secunde după ultimele ei cuvinte.
Fixul: un transcript e dovadă de viață
Corecția e aproape jenantă privind în urmă: un transcript care sosește e cea mai puternică dovadă posibilă că sesiunea nu e inactivă. Nu contează cine a vorbit. Modelul de speech tocmai a recunoscut cuvinte — asta este ședința.
Așa că v2.0.9 ștampilează ceasul de activitate la fiecare transcript care sosește, de la oricare parte. Energia brută din audio-ul de sistem tot nu contează — muzica, tonurile de așteptare și zumzetul de la ventilație tot nu pot imortaliza o sesiune moartă, iar plafonul dur de înregistrare rămâne plasa de siguranță pentru orice. Doar vorbirea recunoscută ține o sesiune în viață, ceea ce e exact granița corectă.
Un detaliu din code review care merită transmis mai departe: prima versiune a fixului ștampila ceasul în interiorul căii de atribuire a vorbitorului — pe care un subset de transcript-uri o poate sări în mod legitim. Review-ul a prins că o schimbare viitoare ar fi putut reintroduce silențios bug-ul exact pentru transcript-urile care contează (ale celuilalt vorbitor). Ștampila e acum necondiționată, înaintea oricărei ramificări, cu un test care pică dacă cineva o mută.
Același release a rezolvat ceva mai înfricoșător
În timp ce testam aceste fix-uri, am dat pe pielea noastră de un alt bug: un crash în procesul de interfață a lăsat întregul desktop imposibil de accesat cu click-ul.
Overlay-ul GeekBye e o fereastră transparentă, always-on-top, care îți acoperă ecranul. E click-through în mod implicit; interfața o comută pe interactiv când folosești un panou. Acele comutări vin din procesul de interfață — așa că atunci când acel proces a crăpat cu un panou deschis, fereastra invizibilă a rămas în modul interactiv fără nicio interfață vie în spate. Fiecare click de pe desktop ateriza pe un panou mort, invizibil. Singura scăpare era închiderea forțată a aplicației.
Handler-ul de crash din v2.0.9 restaurează acum click-through-ul imediat și reîncarcă interfața — cu un plafon de trei reîncărcări pe minut, ca un crash-loop să nu se poată învârti la nesfârșit (peste plafon, aplicația renunță la reîncărcare, dar desktopul tău rămâne utilizabil, care e partea care contează). Code review-ul a ascuțit și acest fix: recuperarea e limitată specific la fereastra de overlay, pentru că aplicarea în orb a click-through-ului pe o fereastră normală crăpată — să zicem, dialogul de update — ar fi creat blocajul invers.
Poți verifica singur acest fix, brutal: deschide un panou GeekBye, omoară forțat procesul "GeekBye Helper (Renderer)" din Activity Monitor și privește cum aplicația îți recuperează desktopul într-o secundă.
Ce ne-a învățat această pereche de bug-uri
- Orice proxy pentru „e utilizatorul aici?" eșuează undeva. Energia microfonului eșuează pentru cei care ascultă. Detecția ferestrelor eșuează pentru browsere. Transcript-urile recunoscute eșuează pentru... nimic din ce am găsit până acum, pentru că nu sunt un proxy — sunt produsul însuși.
- Orice e condus de renderer are nevoie de o poveste de crash. Dacă un proces de UI mort poate lăsa în urmă stare la nivel de OS (capturarea mouse-ului, always-on-top, protecția conținutului), procesul principal trebuie să dețină resetarea.
- Să fii cel mai intens utilizator al propriului produs e o strategie de vânat bug-uri. Ambele bug-uri ne-au lovit în ședințe reale înainte ca mai mult de o mână de clienți să observe. Coloana
ended_reason, adăugată pentru observabilitate cu luni în urmă, e ceea ce a transformat diagnosticul într-o interogare de bază de date în loc de o ghicitoare.
Ambele fix-uri au mers de la diagnostic la un release livrat și notarizat în mai puțin de o zi, fiecare purtat de un PR trecut prin review, cu teste de regresie. Dacă ești pe GeekBye v2, le ai din v2.0.9 prin auto-update.
Pentru restul poveștii acestui release, vezi vecinul din serie de ce transcrierea AI înțelege greșit termenii tehnici (v2.0.11), fundația de fiabilitate din de ce notetaker-ul tău AI se oprește pe Wi-Fi slab și cum overlay-ul rămâne invizibil în timpul partajării ecranului fără să-ți fure click-urile.
