Защо твоят AI notetaker спира записа по средата на срещата

На 2 юли GeekBye прекрати запис на среща сам. Редът в базата данни казва всичко: ended_reason = 'idle', продължителност 519 секунди, 99 транскрипт записа — последният записан две секунди преди приложението да реши, че там няма никого.

Другият участник беше по средата на обяснение. Последният ред на транскрипта е буквално фрагмент от изречение: "...executes it or turns it on or so—".

Не беше първият път. Вечерта преди това друга сесия приключи по същия начин. Две срещи, убити от собствената ни функция за надеждност. Ето диагнозата и фиксът, който излезе в GeekBye v2.0.9 — плюс втори, по-страшен бъг, който поправихме в същото издание.

Добронамерен таймер, който можеше да чува само теб

Idle авто-затварянето съществува с основателна причина. Хората забравят записи да вървят цяла нощ; оставен отворен таб със среща продължава да капе аудио вечно. Затова GeekBye следи за неактивност: след 60 секунди без гласова активност показва малък prompt "Still recording?" („Още ли записваш?"), а 30 секунди по-късно, останал без отговор, прекратява сесията — запазвайки всичко, учтиво.

Недостатъкът беше в една дума: гласова. Часовникът за активност броеше само устойчива енергия от микрофона. Това беше съзнателно дизайнерско решение, и то не глупаво — броенето на сурова енергия от системното аудио би позволило на заглушен, но шумен таб да поддържа мъртва сесия жива до безкрай, а точно този провал функцията съществува да предотврати. Срещите, в които предимно слушаш, трябваше да бъдат покрити от детекцията на прозорци на срещи.

Само че детекцията на срещи не може да види всяка среща. Браузър табове, необичайни клиенти, презентация, която гледаш — недетектирани. И в недетектирана среща, в която слушаш 90 секунди — напълно нормално нещо, докато някой обяснява своя Databricks pipeline — за idle часовника ти си неразличим от празна стая.

Виж времевата линия на убитата сесия: последният транскрипт от нашия микрофон дойде 68 секунди преди края. После 60 секунди говорене на другия човек (транскрибирано перфектно, игнорирано от часовника), незабелязаният prompt, 30-секундното отброяване и убийството — 2 секунди след последните му думи.

Фиксът: транскриптът е доказателство за живот

Корекцията е почти неудобна със задна дата: входящ транскрипт е най-силното възможно доказателство, че сесията не е неактивна. Няма значение кой е говорил. Речевият модел току-що е разпознал думи — това е срещата.

Затова v2.0.9 подпечатва часовника за активност при всеки транскрипт, който пристига, от която и да е страна. Суровата енергия от системното аудио все така не се брои — музика, тонове на изчакване и бръмченето на климатика все така не могат да обезсмъртят мъртва сесия, а твърдият лимит на записа все така подсигурява всичко. Само разпозната реч поддържа сесията жива, което е точно правилната граница.

Един детайл от code review, който си струва да предам: първата версия на фикса подпечатваше часовника вътре в пътя за приписване на говорител — който подмножество от транскриптите може легитимно да пропусне. Ревюто хвана, че бъдеща промяна би могла тихо да върне бъга точно за транскриптите, които имат значение (тези на другия говорещ). Печатът вече е безусловен, преди всякакво разклонение, с тест, който се проваля, ако някой го премести.

Същото издание поправи нещо по-страшно

Докато тествахме тези фиксове, ударихме друг бъг по трудния начин: crash в интерфейсния процес остави целия десктоп некликаем.

Overlay-ят на GeekBye е прозрачен, always-on-top прозорец, покриващ екрана ти. По подразбиране е click-through; интерфейсът го превключва на интерактивен, когато използваш панел. Тези превключвания идват от интерфейсния процес — така че когато този процес crash-на при отворен панел, невидимият прозорец остана в интерактивен режим без жив UI зад него. Всеки клик по десктопа ти попадаше върху мъртво, невидимо стъкло. Единственият изход беше насилствено затваряне на приложението.

Crash handler-ът на v2.0.9 вече възстановява click-through незабавно и презарежда интерфейса — с лимит от три презареждания в минута, за да не може crash-loop да се върти вечно (след лимита приложението се отказва от презареждането, но десктопът ти остава използваем, а точно това е частта, която има значение). Code review изостри и този фикс: възстановяването е ограничено конкретно до overlay прозореца, защото сляпото прилагане на click-through върху crash-нал нормален прозорец — да речем, диалога за обновяване — би създало обратното заключване.

Можеш да провериш този фикс сам, брутално: отвори GeekBye панел, насилствено убий процеса "GeekBye Helper (Renderer)" в Activity Monitor и гледай как приложението възстановява десктопа ти в рамките на секунда.

Какво ни научи тази двойка бъгове

1. Всяко приближение на „тук ли е потребителят?" се проваля някъде. Микрофонната енергия се проваля при слушащите. Детекцията на прозорци се проваля при браузърите. Разпознатите транскрипти се провалят при... нищо, което сме открили досега, защото те не са приближение — те са самият продукт.
2. Всичко, задвижвано от renderer-а, има нужда от crash история. Ако мъртъв UI процес може да остави след себе си състояние на ниво операционна система (mouse capture, always-on-top, content protection), main процесът трябва да притежава ресета.
3. Да си собственият си най-тежък потребител е стратегия за откриване на бъгове. И двата бъга ни удариха в реални срещи, преди повече от шепа клиенти да забележат. Колоната ended_reason, която бяхме добавили за наблюдаемост месеци по-рано, е това, което превърна диагнозата в заявка към базата данни вместо в догадка.

И двата фикса минаха от диагноза до пуснато, нотаризирано издание в рамките на ден, всеки носен от ревюирано PR с регресионни тестове. Ако си на GeekBye v2, ги имаш от v2.0.9 насам чрез auto-update.

За останалата част от историята на това издание виж съседа от поредицата защо AI транскрипцията греши техническите термини (v2.0.11), основите на надеждността в защо твоят AI notetaker спира при лош Wi-Fi и как overlay-ят остава невидим по време на споделяне на екран, без да краде кликовете ти.