Transkripsi Langsung Ketika Firewall Memblokir WebSocket

Ada satu cara yang spesifik dan bikin frustrasi bagi transkripsi real-time untuk gagal di jaringan korporat. Wi-Fi Anda baik-baik saja. HTTPS jalan — Anda bisa memuat situs apa pun. Tapi transkripsi langsung malah... tidak mulai, dan tak ada yang memberi tahu Anda sebabnya.

Biang keroknya adalah sejenis proxy korporat yang mengizinkan lalu lintas HTTPS biasa tapi memblokir upgrade WebSocket — handshake yang mengubah koneksi HTTPS menjadi kanal dua arah yang persisten, yang dibutuhkan transkripsi real-time. Bagi proxy, sebuah WebSocket tampak seperti terowongan tak terpantau yang keluar dari jaringan, jadi ia mematikannya. Bagi Anda, transkripsi rusak diam-diam.

GeekBye v2.0.8 menambahkan fallback otomatis untuk persis hal ini — dan membangunnya menyingkap sebuah bug yang akan membuat seluruh fitur ini tidak melakukan apa-apa.

Kenapa fallback, bukan sekadar retry

Kami sudah menangani jaringan yang labil. Kalau koneksi Anda putus di tengah sesi, GeekBye menyambung ulang dengan backoff dan menyangga audio Anda di buffer supaya tak ada yang hilang — itu fitur terpisah yang dibahas di kenapa AI notetaker Anda berhenti saat Wi-Fi jelek.

Tapi WebSocket yang diblokir bukanlah koneksi yang labil. Mencoba ulang WebSocket yang sama terhadap proxy yang menolak WebSocket akan gagal dengan cara yang sama setiap kali, selamanya. Satu-satunya solusi adalah transport yang berbeda — yang tampak seperti HTTPS biasa yang sudah diizinkan proxy.

Maka v2.0.8 beralih ke transport murni-HTTPS melalui endpoint terautentikasi yang sama:

• Arah bawah (transkrip yang kembali ke Anda): server-sent events — respons HTTPS berumur panjang yang dilihat proxy sebagai unduhan streaming biasa.
• Arah atas (audio Anda yang keluar): request POST berkelompok, masing-masing membawa satu potongan audio dengan nomor urut supaya server bisa merangkainya kembali sesuai urutan meski jaringan mengacak-acaknya.

Tak ada soket persisten, tak ada yang tampak seperti terowongan — cuma request dan respons HTTPS. Kalau sebuah proxy mengizinkan Anda memakai situs web, ia mengizinkan yang ini.

Bug yang nyaris merilis fitur mati

Ini bagian yang layak dibaca. Fallback seharusnya terpicu ketika koneksi WebSocket menghabiskan percobaannya dengan signature transport-terblokir — setiap percobaan gagal di upgrade, tak ada masalah auth atau kuota, setidaknya satu penolakan berbentuk proxy. Proxy yang memblokir WebSocket biasanya menjawab upgrade dengan HTTP 403 Forbidden atau 407.

Masalahnya: kode koneksi kami sudah punya aturan bahwa 403 berarti error autentikasi fatal — berhenti, tampilkan ke pengguna, jangan coba ulang. Yang mana benar hampir di mana-mana. Tapi itu berarti 403 dari proxy pemblokir — persis sinyal yang seharusnya memicu fallback — justru dilempar sebagai error fatal sebelum logika fallback sempat berjalan sama sekali. Hanya putus koneksi mentah (penutupan 1006) yang lolos sampai ke fallback. Jadi fitur ini akan bekerja untuk kasus langka dan gagal diam-diam untuk target utama sebenarnya: proxy korporat.

Kami menangkap ini saat mengeraskan rilis, bukan di produksi. Perbaikannya: 403/407 pada tahap upgrade WebSocket kini diperlakukan sebagai bisa dipulihkan supaya loop koneksi bisa habis sampai ke fallback — sementara kegagalan autentikasi yang asli (yang datang berbeda, setelah upgrade berhasil) tetap gagal cepat, persis seperti sebelumnya. Sebuah regression test kini mematok pembedaannya: 403 proxy pemblokir harus jatuh ke fallback; 403 auth sungguhan tidak boleh.

Sisa pengerasan mengikuti garis paranoid yang sama: timeout pada setiap POST arah atas supaya proxy yang menerima request tapi tak pernah menjawab tidak bisa menghentikan aliran audio, dan jaminan bahwa masalah sign-in yang asli tak akan pernah tertutup diam-diam oleh mesin fallback.

Kami mengujinya terhadap proxy yang benar-benar bermusuhan

Fitur yang seluruh tujuannya adalah bertahan di jaringan yang bermusuhan tidak bisa divalidasi oleh unit test saja — unit test tak punya proxy. Sebelum mengaktifkannya, kami menjalankan aplikasi sungguhan lewat reverse proxy lokal yang dikonfigurasi untuk melakukan persis apa yang dilakukan proxy korporat: meneruskan HTTPS, menolak upgrade WebSocket dengan 403.

Jejak di log adalah buktinya: empat percobaan WebSocket yang diblokir, signature kehabisan yang dikenali, peralihan otomatis ke transport HTTPS, lalu sesi transkripsi sehat selama 96 detik lewat HTTPS murni — 66 segmen transkrip, nol yang hilang. Failover-nya bekerja karena kami menyaksikannya beralih.

Tiga pelajaran yang bisa dibawa

1. "Ia jalan di Wi-Fi labil" dan "ia jalan di balik proxy bermusuhan" adalah jaminan yang berbeda. Yang satu butuh reconnection; yang lain butuh transport yang berbeda. Menyamakan keduanya membiarkan seluruh populasi pengguna korporat rusak diam-diam.
2. Klasifikasi error Anda bisa menyembunyikan fitur Anda sendiri dari dirinya. Aturan yang benar 99% waktu (403 = auth fatal) justru salah persis untuk 1% yang menjadi alasan keberadaan fitur ini. Ketika Anda menambahkan fallback, audit apakah kondisi pemicunya bahkan bisa mencapai fallback.
3. Uji si lawan, bukan cuma jalur mulusnya. Satu-satunya uji jujur untuk "bertahan terhadap proxy pemblokir WebSocket" adalah proxy pemblokir WebSocket. Kami membangun satu.

GeekBye v2.0.8 merilis fallback HTTPS dengan pengaman flag dan tervalidasi. Untuk kerja keandalan yang mendampinginya, lihat kenapa AI notetaker Anda berhenti saat Wi-Fi jelek, dan untuk rilis-rilis tetangga di seri ini, kenapa AI notetaker Anda berhenti merekam di tengah meeting (v2.0.9) dan kenapa transkripsi AI salah mendengar istilah teknis (v2.0.11).