
Por qué tu notetaker con IA deja de grabar en mitad de la reunión
Nuestra propia app terminó dos de nuestras reuniones mientras la otra parte estaba a mitad de frase. El rastro forense llevó a un temporizador de inactividad bienintencionado que solo podía oírte a ti — y a un segundo bug que podía bloquear todo tu escritorio. Ambos corregidos en GeekBye v2.0.9.
El 2 de julio, GeekBye terminó la grabación de una reunión por su cuenta. La fila de la base de datos lo dice todo: ended_reason = 'idle', duración 519 segundos, 99 entradas de transcripción — la última escrita dos segundos antes de que la app decidiera que allí no había nadie.
El otro participante estaba en mitad de una explicación. La última línea de la transcripción es literalmente un fragmento de frase: "...executes it or turns it on or so—".
No era la primera vez. La tarde anterior, otra sesión terminó de la misma manera. Dos reuniones, liquidadas por nuestra propia función de fiabilidad. Este es el diagnóstico y el arreglo que salió en GeekBye v2.0.9 — más un segundo bug, más inquietante, que corregimos en la misma versión.
Un temporizador bienintencionado que solo podía oírte a ti
El autocierre por inactividad existe por una buena razón. La gente olvida grabaciones en marcha toda la noche; una pestaña de reunión que se queda abierta sigue goteando audio para siempre. Así que GeekBye vigila la inactividad: tras 60 segundos sin actividad de voz muestra un pequeño aviso "Still recording?" ("¿Sigues grabando?"), y 30 segundos después, sin respuesta, termina la sesión — guardándolo todo, con educación.
El fallo estaba en una palabra: voz. El reloj de actividad contaba solo la energía sostenida del micrófono. Fue una decisión de diseño deliberada, y no una tontería: contar la energía bruta del audio del sistema permitiría que una pestaña silenciada pero ruidosa mantuviera viva indefinidamente una sesión muerta, que es exactamente el fallo que esta función existe para evitar. Las reuniones en las que sobre todo escuchas se suponía que quedaban cubiertas por la detección de ventanas de reunión.
Salvo que la detección de reuniones no puede ver todas las reuniones. Pestañas del navegador, clientes poco habituales, una presentación que estás viendo: sin detectar. Y en una reunión no detectada en la que escuchas durante 90 segundos —algo completamente normal mientras alguien explica su pipeline de Databricks— eres, para el reloj de inactividad, indistinguible de una sala vacía.
Mira la cronología de la sesión liquidada: la última transcripción de nuestro micrófono llegó 68 segundos antes del final. Después, 60 segundos de la otra persona hablando (transcritos a la perfección, ignorados por el reloj), el aviso que pasó inadvertido, la cuenta atrás de 30 segundos y el corte — 2 segundos después de sus últimas palabras.
El arreglo: una transcripción es prueba de vida
La corrección resulta casi vergonzosa vista en retrospectiva: una transcripción entrante es la evidencia más fuerte posible de que la sesión no está inactiva. No importa quién hablara. El modelo de voz acaba de reconocer palabras — eso es la reunión.
Así que v2.0.9 sella el reloj de actividad con cada transcripción que llega, venga del lado que venga. La energía bruta del audio del sistema sigue sin contar — la música, los tonos de espera y el zumbido del aire acondicionado siguen sin poder inmortalizar una sesión muerta, y el tope duro de grabación sigue respaldándolo todo. Solo el habla reconocida mantiene viva una sesión, que es exactamente la frontera correcta.
Un detalle de la code review que vale la pena contar: la primera versión del arreglo sellaba el reloj dentro de la ruta de atribución de hablante — que un subconjunto de transcripciones puede saltarse legítimamente. La revisión detectó que un cambio futuro podría reintroducir el bug en silencio justo para las transcripciones que importan (las del otro hablante). El sello ahora es incondicional, antes de cualquier bifurcación, con un test que falla si alguien lo mueve.
La misma versión corrigió algo más inquietante
Mientras probábamos estos arreglos, nos topamos con otro bug por las malas: un crash en el proceso de la interfaz dejó todo el escritorio sin responder a los clics.
El overlay de GeekBye es una ventana transparente y siempre en primer plano que cubre tu pantalla. Por defecto deja pasar los clics; la interfaz la vuelve interactiva cuando estás usando un panel. Esos cambios vienen del proceso de la interfaz — así que cuando ese proceso crasheó con un panel abierto, la ventana invisible se quedó en modo interactivo sin ninguna UI viva detrás. Cada clic en tu escritorio aterrizaba en un panel muerto e invisible. La única escapatoria era forzar el cierre de la app.
El manejador de crashes de v2.0.9 ahora restaura el paso de clics de inmediato y recarga la interfaz — con un tope de tres recargas por minuto para que un bucle de crashes no pueda girar para siempre (superado el tope, la app renuncia a recargar, pero tu escritorio sigue usable, que es la parte que importa). La code review también afinó este arreglo: la recuperación está acotada específicamente a la ventana del overlay, porque aplicar el paso de clics a ciegas a una ventana normal crasheada —digamos, el diálogo de actualización— habría creado el bloqueo contrario.
Puedes verificar este arreglo tú mismo, por la vía brutal: abre un panel de GeekBye, fuerza el cierre del proceso "GeekBye Helper (Renderer)" en el Monitor de Actividad y observa cómo la app recupera tu escritorio en un segundo.
Lo que nos enseñó este par de bugs
- Todo proxy de "¿está el usuario aquí?" falla en algún sitio. La energía del micrófono falla con quien escucha. La detección de ventanas falla con los navegadores. Las transcripciones reconocidas fallan con... nada que hayamos encontrado todavía, porque no son un proxy: son el producto en sí.
- Todo lo que dirige el renderer necesita una historia de crash. Si un proceso de UI muerto puede dejar atrás estado a nivel del sistema operativo (captura del ratón, siempre en primer plano, protección de contenido), el proceso principal debe encargarse del reseteo.
- Ser tu propio usuario más intensivo es una estrategia para encontrar bugs. Ambos bugs nos golpearon en reuniones reales antes de que los notara más que un puñado de clientes. La columna
ended_reasonque habíamos añadido meses antes por observabilidad es lo que convirtió el diagnóstico en una consulta a la base de datos en lugar de una conjetura.
Ambos arreglos pasaron del diagnóstico a una versión publicada y notarizada en menos de un día, cada uno con un PR revisado y tests de regresión. Si estás en GeekBye v2, los tienes desde v2.0.9 vía actualización automática.
Para el resto de la historia de esta versión, mira al vecino de la serie por qué la transcripción con IA malinterpreta los términos técnicos (v2.0.11), los cimientos de fiabilidad en por qué tu notetaker con IA se detiene con un Wi-Fi malo y cómo el overlay se mantiene invisible al compartir pantalla sin robarte los clics.


