Dlaczego Twój notatnik AI przerywa nagrywanie w trakcie spotkania

2 lipca GeekBye samo zakończyło nagrywanie spotkania. Wiersz w bazie danych mówi wszystko: ended_reason = 'idle', czas trwania 519 sekund, 99 wpisów transkryptu — ostatni zapisany dwie sekundy przed tym, jak aplikacja uznała, że nikogo nie ma.

Drugi uczestnik był w połowie wyjaśniania. Ostatnia linia transkryptu to dosłownie urwane zdanie: "...executes it or turns it on or so—".

To nie był pierwszy raz. Poprzedniego wieczoru inna sesja zakończyła się tak samo. Dwa spotkania, zabite przez naszą własną funkcję niezawodności. Oto diagnoza i poprawka, która trafiła do GeekBye v2.0.9 — plus drugi, straszniejszy błąd, który naprawiliśmy w tym samym wydaniu.

Dobrze pomyślany timer, który słyszał tylko Ciebie

Automatyczne zamykanie bezczynnych sesji istnieje nie bez powodu. Ludzie zostawiają nagrywanie włączone na noc; otwarta karta ze spotkaniem potrafi sączyć dźwięk w nieskończoność. GeekBye pilnuje więc bezczynności: po 60 sekundach bez aktywności głosowej pokazuje mały monit "Still recording?" (nadal nagrywamy?), a 30 sekund później, bez odpowiedzi, kończy sesję — grzecznie zapisując wszystko.

Wada tkwiła w jednym słowie: głosowej. Zegar aktywności liczył wyłącznie utrzymującą się energię z mikrofonu. To była świadoma decyzja projektowa, i wcale nie głupia — liczenie surowej energii dźwięku systemowego pozwoliłoby wyciszonej, ale hałaśliwej karcie utrzymywać martwą sesję przy życiu w nieskończoność, czyli dokładnie tej awarii ta funkcja ma zapobiegać. Spotkania, na których głównie słuchasz, miało pokrywać wykrywanie okien spotkań.

Tyle że wykrywanie spotkań nie widzi każdego spotkania. Karty przeglądarki, nietypowe klienty, prezentacja, którą oglądasz — niewykryte. A na niewykrytym spotkaniu, na którym słuchasz przez 90 sekund — zupełnie normalna rzecz, gdy ktoś tłumaczy swój pipeline w Databricks — jesteś dla zegara bezczynności nie do odróżnienia od pustego pokoju.

Spójrz na oś czasu zabitej sesji: ostatni transkrypt z naszego mikrofonu pojawił się 68 sekund przed końcem. Potem 60 sekund mówienia drugiej osoby (transkrybowane bezbłędnie, ignorowane przez zegar), niezauważony monit, 30-sekundowe odliczanie i egzekucja — 2 sekundy po jej ostatnich słowach.

Poprawka: transkrypt jest dowodem życia

Z perspektywy czasu korekta jest niemal żenująca: przychodzący transkrypt to najsilniejszy możliwy dowód, że sesja nie jest bezczynna. Nie ma znaczenia, kto mówił. Model mowy właśnie rozpoznał słowa — to jest spotkanie.

Dlatego v2.0.9 aktualizuje zegar aktywności przy każdym transkrypcie, który przychodzi — z dowolnej strony. Surowa energia dźwięku systemowego nadal się nie liczy — muzyka, dźwięki oczekiwania na linii i szum klimatyzacji wciąż nie mogą unieśmiertelnić martwej sesji, a twardy limit czasu nagrywania nadal zabezpiecza całość. Tylko rozpoznana mowa utrzymuje sesję przy życiu, i to jest dokładnie właściwa granica.

Jeden szczegół z code review wart przekazania: pierwsza wersja poprawki aktualizowała zegar wewnątrz ścieżki przypisywania mówcy — którą część transkryptów może zgodnie z projektem pominąć. Review wychwyciło, że przyszła zmiana mogłaby po cichu przywrócić błąd dokładnie dla tych transkryptów, które się liczą (drugiego mówcy). Aktualizacja jest teraz bezwarunkowa, przed jakimkolwiek rozgałęzieniem, z testem, który nie przejdzie, jeśli ktoś ją przeniesie.

To samo wydanie naprawiło coś straszniejszego

Testując te poprawki, boleśnie natrafiliśmy na inny błąd: awaria procesu interfejsu zostawiła cały pulpit niereagujący na kliknięcia.

Nakładka GeekBye to przezroczyste okno zawsze na wierzchu, pokrywające cały ekran. Domyślnie przepuszcza kliknięcia; interfejs przełącza je w tryb interaktywny, gdy korzystasz z panelu. Te przełączenia pochodzą z procesu interfejsu — więc gdy ten proces uległ awarii przy otwartym panelu, niewidzialne okno zostało w trybie interaktywnym bez żadnego żywego UI za sobą. Każde kliknięcie na pulpicie lądowało na martwej, niewidzialnej tafli. Jedynym wyjściem było wymuszenie zamknięcia aplikacji.

Handler awarii w v2.0.9 natychmiast przywraca przepuszczanie kliknięć i przeładowuje interfejs — z limitem trzech przeładowań na minutę, żeby pętla awarii nie mogła kręcić się w nieskończoność (po przekroczeniu limitu aplikacja rezygnuje z przeładowywania, ale pulpit pozostaje używalny, a to jest ta część, która się liczy). Code review zaostrzyło i tę poprawkę: odzyskiwanie jest ograniczone konkretnie do okna nakładki, bo hurtowe włączanie przepuszczania kliknięć w awariującym zwykłym oknie — powiedzmy, oknie dialogowym aktualizacji — stworzyłoby odwrotną blokadę.

Możesz zweryfikować tę poprawkę samodzielnie, brutalnie: otwórz panel GeekBye, wymuś zabicie procesu "GeekBye Helper (Renderer)" w Monitorze aktywności i patrz, jak aplikacja odzyskuje Twój pulpit w ciągu sekundy.

Czego nauczyła nas ta para błędów

1. Każdy zastępczy sygnał dla pytania "czy użytkownik tu jest?" gdzieś zawodzi. Energia mikrofonu zawodzi u słuchających. Wykrywanie okien zawodzi w przeglądarkach. Rozpoznane transkrypty zawodzą przy... niczym, co dotąd znaleźliśmy, bo nie są sygnałem zastępczym — są samym produktem.
2. Wszystko, co sterowane przez renderer, potrzebuje scenariusza na wypadek awarii. Jeśli martwy proces UI może zostawić po sobie stan na poziomie systemu (przechwytywanie myszy, zawsze na wierzchu, ochronę treści), reset musi należeć do procesu głównego.
3. Bycie swoim własnym najcięższym użytkownikiem to strategia znajdowania błędów. Oba błędy uderzyły w nas na prawdziwych spotkaniach, zanim zauważyła je więcej niż garstka klientów. Kolumna ended_reason, którą dodaliśmy dla obserwowalności miesiące wcześniej, sprawiła, że diagnoza była zapytaniem do bazy danych, a nie zgadywaniem.

Obie poprawki przeszły drogę od diagnozy do opublikowanego, notaryzowanego wydania w ciągu jednego dnia, każda w zrecenzowanym PR z testami regresji. Jeśli używasz GeekBye v2, masz je od v2.0.9 przez automatyczną aktualizację.

Resztę historii tego wydania znajdziesz w sąsiednim artykule serii dlaczego transkrypcja AI przekręca terminy techniczne (v2.0.11), w fundamencie niezawodności w artykule dlaczego Twój notatnik AI przestaje działać na słabym Wi-Fi oraz w tym, jak nakładka pozostaje niewidoczna podczas udostępniania ekranu, nie kradnąc Twoich kliknięć.