
Per què el teu assistent de notes amb IA deixa de gravar a mitja reunió
La nostra pròpia app va tallar dues de les nostres reunions mentre l'altra banda era a mitja frase. El rastre forense va portar a un temporitzador d'inactivitat ben intencionat que només et podia sentir a tu — i a un segon bug que podia bloquejar tot l'escriptori. Tots dos corregits a GeekBye v2.0.9.
El 2 de juliol, GeekBye va acabar una gravació de reunió pel seu compte. La fila de la base de dades ho diu tot: ended_reason = 'idle', durada 519 segons, 99 entrades de transcripció — l'última escrita dos segons abans que l'app decidís que no hi havia ningú.
L'altre participant era a mitja explicació. L'última línia del transcript és literalment un fragment de frase: "...executes it or turns it on or so—".
No era la primera vegada. El vespre anterior, una altra sessió havia acabat de la mateixa manera. Dues reunions, mortes per la nostra pròpia funcionalitat de fiabilitat. Aquí teniu la diagnosi i la correcció publicada a GeekBye v2.0.9 — més un segon bug, encara més inquietant, que vam corregir a la mateixa versió.
Un temporitzador ben intencionat que només et podia sentir a tu
El tancament automàtic per inactivitat existeix per una bona raó. La gent oblida gravacions en marxa tota la nit; una pestanya de reunió deixada oberta continua degotant àudio per sempre. Així que GeekBye vigila la inactivitat: després de 60 segons sense activitat de veu mostra un petit avís "Still recording?" ("Encara gravant?"), i 30 segons més tard, sense resposta, acaba la sessió — desant-ho tot, educadament.
El defecte era en una sola paraula: veu. El rellotge d'activitat només comptava energia sostinguda del micròfon. Va ser una decisió de disseny deliberada, i no pas estúpida — comptar l'energia bruta de l'àudio del sistema permetria que una pestanya silenciada però sorollosa mantingués viva una sessió morta indefinidament, que és exactament la fallada que la funcionalitat ha d'evitar. Les reunions on sobretot escoltes se suposava que quedaven cobertes per la detecció de finestres de reunió.
Però la detecció de reunions no pot veure totes les reunions. Pestanyes del navegador, clients inusuals, una presentació que mires — sense detectar. I en una reunió no detectada on escoltes durant 90 segons — una cosa completament normal mentre algú explica el seu pipeline de Databricks — ets, per al rellotge d'inactivitat, indistingible d'una habitació buida.
Mireu la cronologia de la sessió morta: l'últim transcript del nostre micròfon va arribar 68 segons abans del final. Després, 60 segons de l'altra persona parlant (transcrits perfectament, ignorats pel rellotge), l'avís que ningú no va veure, el compte enrere de 30 segons, i el tall — 2 segons després de les seves últimes paraules.
La correcció: una transcripció és prova de vida
La correcció és gairebé vergonyosa en retrospectiva: una transcripció entrant és l'evidència més forta possible que la sessió no està inactiva. No importa qui parlava. El model de veu acaba de reconèixer paraules — això és la reunió.
Així que la v2.0.9 marca el rellotge d'activitat amb cada transcripció que arriba, de qualsevol de les dues bandes. L'energia bruta de l'àudio del sistema continua sense comptar — la música, els tons d'espera i el brunzit de l'aire condicionat continuen sense poder immortalitzar una sessió morta, i el límit dur de gravació continua fent de xarxa de seguretat. Només la parla reconeguda manté viva una sessió, que és exactament la frontera correcta.
Un detall de la revisió de codi que val la pena compartir: la primera versió de la correcció marcava el rellotge dins del camí d'atribució de parlant — que un subconjunt de transcripcions pot saltar-se legítimament. La revisió va detectar que un canvi futur podria reintroduir silenciosament el bug exactament per a les transcripcions que importen (les de l'altre interlocutor). Ara la marca és incondicional, abans de qualsevol bifurcació, amb un test que falla si algú la mou.
La mateixa versió va corregir una cosa més inquietant
Mentre provàvem aquestes correccions, vam topar de cara amb un bug diferent: un crash al procés de la interfície va deixar tot l'escriptori sense poder-hi clicar.
L'overlay de GeekBye és una finestra transparent, sempre en primer pla, que cobreix la pantalla. Per defecte deixa passar els clics; la interfície la commuta a interactiva quan fas servir un panell. Aquestes commutacions vénen del procés de la interfície — així que quan aquell procés va petar amb un panell obert, la finestra invisible es va quedar en mode interactiu sense cap UI viva al darrere. Cada clic a l'escriptori aterrava sobre un panell mort i invisible. L'única sortida era forçar el tancament de l'app.
El gestor de crashos de la v2.0.9 ara restaura immediatament el pas de clics i recarrega la interfície — amb un límit de tres recàrregues per minut perquè un bucle de crashos no pugui girar per sempre (superat el límit, l'app renuncia a recarregar però el teu escriptori continua sent usable, que és la part que importa). La revisió de codi també va esmolar aquesta: la recuperació està limitada específicament a la finestra de l'overlay, perquè aplicar el pas de clics a cegues a una finestra normal que ha petat — per exemple, el diàleg d'actualització — hauria creat el bloqueig contrari.
Pots verificar aquesta correcció tu mateix, brutalment: obre un panell de GeekBye, mata a la força el procés "GeekBye Helper (Renderer)" al Monitor d'Activitat, i mira com l'app et recupera l'escriptori en menys d'un segon.
Què ens va ensenyar aquesta parella de bugs
- Tot proxy de "l'usuari encara hi és?" falla en algun lloc. L'energia del micròfon falla per als qui escolten. La detecció de finestres falla per als navegadors. Les transcripcions reconegudes fallen per a... res que hàgim trobat encara, perquè no són un proxy — són el producte mateix.
- Tot allò governat pel renderer necessita una història de crash. Si un procés d'UI mort pot deixar estat a nivell de sistema operatiu (captura del ratolí, sempre en primer pla, protecció de contingut), el procés principal ha de ser l'amo del reset.
- Ser el teu propi usuari més intensiu és una estratègia per trobar bugs. Tots dos bugs ens van tocar en reunions reals abans que més d'un grapat de clients se n'adonés. La columna
ended_reasonque havíem afegit per observabilitat mesos abans és el que va convertir la diagnosi en una consulta a la base de dades en lloc d'una endevinalla.
Totes dues correccions van passar de la diagnosi a una versió publicada i notaritzada en menys d'un dia, cadascuna portada per una PR revisada amb tests de regressió. Si ets a GeekBye v2, les tens des de la v2.0.9 via actualització automàtica.
Per a la resta de la història d'aquesta versió, mira la veïna de sèrie per què la transcripció amb IA sent malament els termes tècnics (v2.0.11), els fonaments de fiabilitat a per què el teu notetaker d'IA s'atura amb mala Wi-Fi, i com l'overlay es manté invisible mentre comparteixes pantalla sense robar-te els clics.


