Perché il Tuo Notetaker AI Smette di Registrare a Metà Riunione

Il 2 luglio, GeekBye ha terminato da solo la registrazione di una riunione. La riga nel database dice tutto: ended_reason = 'idle', durata 519 secondi, 99 voci di trascrizione — l'ultima scritta due secondi prima che l'app decidesse che non c'era nessuno.

L'altro partecipante era nel mezzo di una spiegazione. L'ultima riga della trascrizione è letteralmente un frammento di frase: "...executes it or turns it on or so—".

Non era la prima volta. La sera prima, un'altra sessione era finita allo stesso modo. Due riunioni, uccise dalla nostra stessa funzione di affidabilità. Ecco la diagnosi e il fix uscito in GeekBye v2.0.9 — più un secondo bug, più inquietante, corretto nella stessa release.

Un timer ben intenzionato che riusciva a sentire solo te

La chiusura automatica per inattività esiste per una buona ragione. La gente dimentica registrazioni accese tutta la notte; una scheda di riunione lasciata aperta continua a sgocciolare audio per sempre. Così GeekBye sorveglia l'inattività: dopo 60 secondi senza attività vocale mostra un piccolo avviso "Still recording?" ("Stai ancora registrando?"), e 30 secondi dopo, senza risposta, termina la sessione — salvando tutto, con garbo.

Il difetto stava in una parola: vocale. L'orologio dell'attività contava solo l'energia sostenuta del microfono. Era una decisione di design deliberata, e non stupida: contare l'energia grezza dell'audio di sistema permetterebbe a una scheda silenziata ma rumorosa di tenere in vita all'infinito una sessione morta, che è esattamente il guasto che la funzione esiste per prevenire. Le riunioni in cui per lo più ascolti dovevano essere coperte dal rilevamento delle finestre di riunione.

Se non che il rilevamento delle riunioni non può vedere ogni riunione. Schede del browser, client inconsueti, una presentazione che stai guardando: non rilevati. E in una riunione non rilevata in cui ascolti per 90 secondi — una cosa del tutto normale mentre qualcuno spiega la sua pipeline Databricks — per l'orologio dell'inattività sei indistinguibile da una stanza vuota.

Guarda la cronologia della sessione uccisa: l'ultima trascrizione dal nostro microfono è arrivata 68 secondi prima della fine. Poi 60 secondi dell'altra persona che parla (trascritti alla perfezione, ignorati dall'orologio), l'avviso passato inosservato, il conto alla rovescia di 30 secondi e il colpo finale — 2 secondi dopo le sue ultime parole.

Il fix: una trascrizione è prova di vita

La correzione è quasi imbarazzante col senno di poi: una trascrizione in arrivo è la prova più forte possibile che la sessione non è inattiva. Non importa chi abbia parlato. Il modello vocale ha appena riconosciuto delle parole — quella è la riunione.

Così la v2.0.9 timbra l'orologio dell'attività a ogni trascrizione che arriva, da entrambi i lati. L'energia grezza dell'audio di sistema continua a non contare — musica, toni di attesa e ronzio dell'aria condizionata continuano a non poter immortalare una sessione morta, e il tetto massimo di registrazione resta a fare da ultima rete di sicurezza. Solo il parlato riconosciuto tiene in vita una sessione, che è precisamente il confine giusto.

Un dettaglio emerso in code review che vale la pena tramandare: la prima versione del fix timbrava l'orologio dentro il percorso di attribuzione del parlante — che un sottoinsieme di trascrizioni può legittimamente saltare. La review ha colto che una modifica futura avrebbe potuto reintrodurre il bug in silenzio proprio per le trascrizioni che contano (quelle dell'altro parlante). Il timbro ora è incondizionato, prima di qualsiasi diramazione, con un test che fallisce se qualcuno lo sposta.

La stessa release ha corretto qualcosa di più inquietante

Mentre testavamo questi fix, ci siamo imbattuti nel modo peggiore in un bug diverso: un crash nel processo dell'interfaccia ha lasciato l'intero desktop non cliccabile.

L'overlay di GeekBye è una finestra trasparente, sempre in primo piano, che copre lo schermo. Di default lascia passare i clic; l'interfaccia la rende interattiva quando stai usando un pannello. Quei passaggi arrivano dal processo dell'interfaccia — così, quando quel processo è andato in crash mentre un pannello era aperto, la finestra invisibile è rimasta in modalità interattiva senza alcuna UI viva dietro. Ogni clic sul desktop atterrava su un pannello morto e invisibile. L'unica via d'uscita era forzare la chiusura dell'app.

Il gestore dei crash della v2.0.9 ora ripristina immediatamente il click-through e ricarica l'interfaccia — con un tetto di tre ricaricamenti al minuto, così un loop di crash non può girare all'infinito (oltre il tetto, l'app rinuncia a ricaricare, ma il desktop resta usabile, che è la parte che conta). Anche qui la code review ha affilato il risultato: il ripristino è circoscritto specificamente alla finestra dell'overlay, perché applicare il click-through in blocco a una finestra normale in crash — per esempio la finestra di dialogo degli aggiornamenti — avrebbe creato il blocco opposto.

Puoi verificare questo fix da solo, brutalmente: apri un pannello di GeekBye, forza la chiusura del processo "GeekBye Helper (Renderer)" in Monitoraggio Attività e guarda l'app restituirti il desktop entro un secondo.

Cosa ci ha insegnato questa coppia di bug

1. Ogni proxy per "l'utente è ancora qui?" fallisce da qualche parte. L'energia del microfono fallisce con chi ascolta. Il rilevamento delle finestre fallisce con i browser. Le trascrizioni riconosciute falliscono con... niente che abbiamo trovato finora, perché non sono un proxy — sono il prodotto stesso.
2. Tutto ciò che è guidato dal renderer ha bisogno di una storia di crash. Se un processo UI morto può lasciarsi dietro stato a livello di sistema operativo (cattura del mouse, sempre in primo piano, protezione dei contenuti), il processo principale deve possedere il reset.
3. Essere i propri utenti più assidui è una strategia per trovare bug. Entrambi i bug ci hanno colpito in riunioni reali prima che se ne accorgesse più di una manciata di clienti. La colonna ended_reason che avevamo aggiunto mesi prima per l'osservabilità è ciò che ha trasformato la diagnosi in una query al database invece che in un'ipotesi.

Entrambi i fix sono passati dalla diagnosi a una release pubblicata e notarizzata in un giorno, ciascuno portato da una PR revisionata con test di regressione. Se sei su GeekBye v2, li hai dalla v2.0.9 via aggiornamento automatico.

Per il resto della storia di questa release, vedi il vicino di serie perché la trascrizione AI fraintende i termini tecnici (v2.0.11), le fondamenta di affidabilità in perché il tuo notetaker AI si ferma con un Wi-Fi instabile e come l'overlay resta invisibile durante la condivisione dello schermo senza rubarti i clic.