Почему ваш ИИ-ассистент для заметок останавливает запись посреди встречи

2 июля GeekBye само завершило запись встречи. Строка в базе данных говорит всё: ended_reason = 'idle', длительность 519 секунд, 99 записей транскрипта — последняя записана за две секунды до того, как приложение решило, что здесь никого нет.

Собеседник был на середине объяснения. Последняя строка транскрипта — буквально обрывок фразы: «...executes it or turns it on or so—».

Это было не в первый раз. Накануне вечером другая сессия закончилась так же. Две встречи, убитые нашей собственной функцией надёжности. Вот диагноз и фикс, вышедший в GeekBye v2.0.9, — плюс второй, более страшный баг, который мы исправили в том же релизе.

Благонамеренный таймер, который слышал только вас

Автозакрытие по бездействию существует не просто так. Люди забывают запись включённой на ночь; оставленная открытой вкладка со встречей может сочиться звуком вечно. Поэтому GeekBye следит за неактивностью: после 60 секунд без голосовой активности он показывает небольшой вопрос «Still recording?» (всё ещё записываем?), а через 30 секунд без ответа завершает сессию — вежливо всё сохранив.

Изъян был в одном слове: голосовой. Часы активности считали только устойчивую энергию с микрофона. Это было осознанное проектное решение, и не глупое — учёт сырой энергии системного звука позволил бы заглушённой, но шумной вкладке держать мёртвую сессию живой бесконечно, а это ровно тот отказ, который функция и должна предотвращать. Встречи, где вы в основном слушаете, должно было покрывать определение окон встреч.

Вот только определение встреч видит не каждую встречу. Вкладки браузера, необычные клиенты, презентация, которую вы смотрите, — не распознаются. И на нераспознанной встрече, где вы слушаете 90 секунд — совершенно нормальное дело, пока кто-то объясняет свой пайплайн в Databricks, — вы для часов бездействия неотличимы от пустой комнаты.

Посмотрите на таймлайн убитой сессии: последний транскрипт с нашего микрофона пришёл за 68 секунд до конца. Затем 60 секунд говорил собеседник (транскрибировано идеально, часами проигнорировано), незамеченный вопрос, 30-секундный отсчёт и убийство — через 2 секунды после его последних слов.

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

Задним числом исправление почти неловкое: входящий транскрипт — сильнейшее возможное доказательство того, что сессия не бездействует. Неважно, кто говорил. Речевая модель только что распознала слова — это и есть встреча.

Поэтому v2.0.9 обновляет часы активности на каждом приходящем транскрипте, с любой стороны. Сырая энергия системного звука по-прежнему не считается — музыка, гудки ожидания и гул вентиляции всё так же не могут обессмертить мёртвую сессию, а жёсткий лимит длительности записи по-прежнему страхует всё. Только распознанная речь держит сессию живой — и это ровно та граница, которая нужна.

Одна деталь из код-ревью, которой стоит поделиться: первая версия фикса обновляла часы внутри пути атрибуции говорящего — который часть транскриптов может легитимно пропускать. Ревью поймало, что будущее изменение могло бы молча вернуть баг ровно для тех транскриптов, которые важны (собеседника). Теперь обновление безусловное, до любого ветвления, с тестом, который падает, если кто-то его сдвинет.

Тот же релиз исправил кое-что пострашнее

Тестируя эти фиксы, мы наткнулись на другой баг самым жёстким способом: сбой процесса интерфейса оставил весь рабочий стол некликабельным.

Оверлей GeekBye — прозрачное окно поверх всех окон, покрывающее экран. По умолчанию оно пропускает клики; интерфейс переключает его в интерактивный режим, когда вы пользуетесь панелью. Эти переключения приходят из процесса интерфейса — поэтому, когда тот процесс упал при открытой панели, невидимое окно осталось в интерактивном режиме без живого UI за ним. Каждый клик по рабочему столу попадал в мёртвую невидимую панель. Единственным выходом было принудительно закрыть приложение.

Обработчик сбоев в v2.0.9 теперь немедленно возвращает пропуск кликов и перезагружает интерфейс — с лимитом в три перезагрузки в минуту, чтобы цикл сбоев не мог крутиться вечно (после лимита приложение перестаёт перезагружать, но рабочий стол остаётся работоспособным — а это и есть главное). Код-ревью отточило и этот фикс: восстановление ограничено именно окном оверлея, потому что огульное включение пропуска кликов у упавшего обычного окна — скажем, диалога обновления — создало бы обратную блокировку.

Вы можете проверить этот фикс сами, жёстко: откройте панель GeekBye, принудительно завершите процесс «GeekBye Helper (Renderer)» в Мониторинге системы и посмотрите, как приложение возвращает вам рабочий стол в течение секунды.

Чему нас научила эта пара багов

1. Любой косвенный признак «пользователь здесь?» где-то отказывает. Энергия микрофона отказывает на слушателях. Определение окон отказывает на браузерах. Распознанные транскрипты отказывают на... мы пока не нашли, на чём, потому что это не косвенный признак — это сам продукт.
2. Всему, что управляется рендерером, нужен сценарий на случай сбоя. Если мёртвый процесс UI может оставить за собой состояние на уровне ОС (захват мыши, поверх всех окон, защита контента), сбросом должен владеть главный процесс.
3. Быть собственным самым активным пользователем — это стратегия поиска багов. Оба бага ударили по нам на реальных встречах раньше, чем их заметила больше чем горстка клиентов. Колонка ended_reason, добавленная ради наблюдаемости за месяцы до этого, превратила диагноз в запрос к базе данных вместо гадания.

Оба фикса прошли путь от диагноза до выпущенного нотаризованного релиза за один день, каждый — в отревьюенном PR с регрессионными тестами. Если вы на GeekBye v2, они у вас с v2.0.9 через автообновление.

Остальную часть истории этого релиза читайте в соседней статье серии почему ИИ-транскрипция перевирает технические термины (v2.0.11), в фундаменте надёжности в статье почему ваш ИИ-ассистент останавливается на плохом Wi-Fi и в том, как оверлей остаётся невидимым во время демонстрации экрана, не воруя ваши клики.