Mengapa AI Notetaker Anda Berhenti Merekam di Tengah Meeting

Pada 2 Juli, GeekBye mengakhiri sebuah rekaman meeting atas kemauannya sendiri. Baris database-nya berbicara jelas: ended_reason = 'idle', durasi 519 detik, 99 entri transkrip — yang terakhir tertulis dua detik sebelum aplikasi memutuskan tidak ada orang di sana.

Peserta satunya sedang di tengah penjelasan. Baris terakhir transkripnya benar-benar potongan kalimat: "...executes it or turns it on or so—".

Itu bukan yang pertama. Malam sebelumnya, sesi lain berakhir dengan cara yang sama. Dua meeting, dibunuh oleh fitur keandalan kami sendiri. Inilah diagnosis dan perbaikan yang dirilis di GeekBye v2.0.9 — plus bug kedua yang lebih menyeramkan yang kami perbaiki di rilis yang sama.

Timer berniat baik yang hanya bisa mendengar Anda

Auto-close idle ada karena alasan yang bagus. Orang lupa mematikan rekaman semalaman; tab meeting yang dibiarkan terbuka terus meneteskan audio selamanya. Jadi GeekBye mengawasi inaktivitas: setelah 60 detik tanpa aktivitas suara, ia menampilkan prompt kecil "Still recording?" ("Masih merekam?"), dan 30 detik kemudian, jika tak dijawab, ia mengakhiri sesi — menyimpan semuanya, dengan sopan.

Cacatnya ada di satu kata: suara. Jam aktivitas hanya menghitung energi mikrofon yang berkelanjutan. Itu keputusan desain yang disengaja, dan bukan keputusan bodoh — menghitung energi mentah audio sistem akan membuat tab yang di-mute tapi berisik bisa mempertahankan sesi mati tanpa batas, persis kegagalan yang fitur ini ada untuk mencegahnya. Meeting di mana Anda kebanyakan mendengarkan seharusnya tercakup oleh deteksi jendela meeting.

Masalahnya, deteksi meeting tidak bisa melihat semua meeting. Tab browser, klien yang tidak umum, presentasi yang Anda tonton — tidak terdeteksi. Dan di meeting yang tidak terdeteksi, saat Anda mendengarkan selama 90 detik — hal yang sepenuhnya normal ketika seseorang menjelaskan pipeline Databricks-nya — Anda, di mata jam idle, tidak bisa dibedakan dari ruangan kosong.

Lihat linimasa sesi yang terbunuh itu: transkrip terakhir dari mikrofon kami datang 68 detik sebelum akhir. Lalu 60 detik orang satunya berbicara (ditranskripsi dengan sempurna, diabaikan oleh jam), prompt yang tak disadari, hitung mundur 30 detik, dan penghentian — 2 detik setelah kata-kata terakhir mereka.

Perbaikannya: transkrip adalah bukti kehidupan

Koreksinya hampir memalukan kalau dipikir-pikir: transkrip yang masuk adalah bukti terkuat yang mungkin bahwa sesi tidak sedang idle. Tidak penting siapa yang bicara. Model suara baru saja mengenali kata-kata — itulah meeting itu sendiri.

Maka v2.0.9 mencap jam aktivitas pada setiap transkrip yang tiba, dari sisi mana pun. Energi mentah audio sistem tetap tidak dihitung — musik, nada tunggu, dan dengung AC tetap tidak bisa mengabadikan sesi yang mati, dan batas keras durasi rekaman tetap menjadi pengaman terakhir. Hanya ucapan yang dikenali yang menjaga sesi tetap hidup, dan itu persis batas yang tepat.

Satu detail dari code review yang layak diteruskan: versi pertama perbaikan mencap jam di dalam jalur atribusi pembicara — yang secara sah bisa dilewati oleh sebagian transkrip. Review menangkap bahwa perubahan di masa depan bisa diam-diam menghidupkan lagi bug ini justru untuk transkrip yang paling penting (milik lawan bicara). Cap itu kini tanpa syarat, sebelum percabangan apa pun, dengan tes yang gagal jika ada yang memindahkannya.

Rilis yang sama memperbaiki sesuatu yang lebih menyeramkan

Saat menguji perbaikan ini, kami menabrak bug lain dengan cara yang menyakitkan: crash di proses antarmuka membuat seluruh desktop tidak bisa diklik.

Overlay GeekBye adalah jendela transparan yang selalu di atas dan menutupi layar Anda. Secara default ia meneruskan klik (click-through); antarmuka mengubahnya jadi interaktif saat Anda memakai panel. Perintah pengubahan itu datang dari proses antarmuka — jadi ketika proses itu crash saat panel terbuka, jendela tak terlihat itu tertahan di mode interaktif tanpa UI hidup di baliknya. Setiap klik di desktop Anda mendarat di panel mati yang tak terlihat. Satu-satunya jalan keluar adalah force-quit aplikasinya.

Penangan crash v2.0.9 kini langsung memulihkan click-through dan memuat ulang antarmuka — dengan batas tiga kali muat ulang per menit agar crash-loop tidak berputar selamanya (melewati batas itu, aplikasi menyerah memuat ulang tapi desktop Anda tetap bisa dipakai, dan itulah bagian yang penting). Code review juga mempertajam yang ini: pemulihan dibatasi khusus ke jendela overlay, karena menerapkan click-through secara membabi buta ke jendela normal yang crash — misalnya dialog update — justru akan menciptakan penguncian sebaliknya.

Anda bisa memverifikasi perbaikan ini sendiri, dengan cara brutal: buka panel GeekBye, force-kill proses "GeekBye Helper (Renderer)" di Activity Monitor, dan saksikan aplikasi memulihkan desktop Anda dalam sedetik.

Pelajaran dari sepasang bug ini

1. Setiap proksi untuk "apakah pengguna masih di sini?" gagal di suatu tempat. Energi mikrofon gagal untuk pendengar. Deteksi jendela gagal untuk browser. Transkrip yang dikenali gagal untuk... belum ada yang kami temukan, karena mereka bukan proksi — mereka adalah produknya itu sendiri.
2. Apa pun yang dikendalikan renderer butuh cerita crash. Jika proses UI yang mati bisa meninggalkan state di level OS (penangkapan mouse, selalu di atas, proteksi konten), proses utama harus memiliki resetnya.
3. Menjadi pengguna terberat produk sendiri adalah strategi menemukan bug. Kedua bug menghantam kami di meeting sungguhan sebelum lebih dari segelintir pelanggan menyadarinya. Kolom ended_reason yang kami tambahkan untuk observability berbulan-bulan sebelumnya adalah yang membuat diagnosis ini menjadi query database, bukan tebakan.

Kedua perbaikan berjalan dari diagnosis hingga rilis ter-notarisasi yang dipublikasikan dalam sehari, masing-masing dibawa oleh PR yang direview dengan tes regresi. Jika Anda memakai GeekBye v2, Anda sudah mendapatkannya sejak v2.0.9 lewat auto-update.

Untuk sisa cerita rilis ini, lihat tetangga serinya mengapa transkripsi AI salah mendengar istilah teknis (v2.0.11), fondasi keandalan di mengapa AI notetaker Anda berhenti di Wi-Fi buruk, dan bagaimana overlay tetap tak terlihat saat berbagi layar tanpa mencuri klik Anda.