Live transcriptie wanneer de firewall WebSockets blokkeert

Er bestaat een specifieke, tot waanzin drijvende manier waarop real-time transcriptie faalt op een bedrijfsnetwerk. Je wifi is prima. HTTPS werkt — je kunt elke website laden. Maar live transcriptie start gewoon... niet, en niets vertelt je waarom.

De boosdoener is een soort bedrijfsproxy die gewoon HTTPS-verkeer toestaat maar de WebSocket-upgrade blokkeert — de handshake die een HTTPS-verbinding verandert in het persistente, tweerichtingskanaal dat real-time transcriptie nodig heeft. Voor de proxy ziet een WebSocket eruit als een niet-gemonitorde tunnel het netwerk uit, dus die kill hij. Voor jou is transcriptie in stilte kapot.

GeekBye v2.0.8 voegde een automatische fallback toe voor precies dit — en het bouwen ervan bracht een bug aan het licht die de hele feature niets zou hebben laten doen.

Waarom een fallback, niet gewoon een retry

We handelen wispelturige netwerken al af. Als je verbinding midden in een sessie wegvalt, verbindt GeekBye opnieuw met backoff en buffert je audio zodat er niets verloren gaat — dat is een aparte feature, behandeld in waarom je AI-notulist stopt bij slechte wifi.

Maar een geblokkeerde WebSocket is geen wispelturige verbinding. Dezelfde WebSocket opnieuw proberen tegen een proxy die WebSockets weigert, faalt elke keer op dezelfde manier, voor altijd. De enige fix is een ander transport — een dat eruitziet als de gewone HTTPS die de proxy al toelaat.

Dus v2.0.8 valt terug op een puur-HTTPS-transport over hetzelfde geauthenticeerde endpoint:

• Downstream (transcripties die naar je terugkomen): server-sent events — een langlevend HTTPS-antwoord dat de proxy ziet als een gewone gestreamde download.
• Upstream (je audio die naar buiten gaat): gebatchte POST-verzoeken, elk met een chunk audio en een volgnummer zodat de server ze op volgorde kan samenstellen, zelfs als het netwerk ze herordent.

Geen persistente socket, niets wat op een tunnel lijkt — alleen HTTPS-verzoeken en -antwoorden. Als een proxy je een website laat gebruiken, laat hij dit toe.

De bug die een dode feature had uitgeleverd

Dit is het deel dat het lezen waard is. De fallback hoort te triggeren wanneer de WebSocket-verbinding haar pogingen uitput met een geblokkeerd-transport-signatuur — elke poging faalt op de upgrade, geen auth- of quotaprobleem, minstens één proxy-vormige afwijzing. Een proxy die een WebSocket blokkeert, beantwoordt de upgrade doorgaans met een HTTP 403 Forbidden of 407.

Het probleem: onze verbindingscode had al een regel dat een 403 betekent fatale authenticatiefout — stop, toon hem aan de gebruiker, niet opnieuw proberen. Wat bijna overal correct is. Maar het betekende dat de 403 van een blokkerende proxy — precies het signaal dat de fallback had moeten triggeren — in plaats daarvan als een fatale fout werd gegooid voordat de fallbacklogica ooit kon draaien. Alleen een kale verbindingsval (een 1006-sluiting) viel door naar de fallback. Dus de feature zou hebben gewerkt voor het zeldzame geval en in stilte gefaald voor zijn eigenlijke primaire doelwit: de bedrijfsproxy.

We vingen dit tijdens het harden van de release, niet in productie. De fix: een 403/407 op het WebSocket-upgrade-been wordt nu als herstelbaar behandeld zodat de verbindingslus kan uitputten naar de fallback — terwijl een echte authenticatiefout (die anders binnenkomt, nadat de upgrade slaagt) nog steeds snel faalt, precies als voorheen. Een regressietest legt het onderscheid nu vast: een geblokkeerde-proxy-403 moet terugvallen; een echte auth-403 mag dat niet.

De rest van het harden volgde dezelfde paranoïde lijn: een timeout op elke upstream-POST zodat een proxy die een verzoek accepteert maar nooit antwoordt de audiostroom niet kan blokkeren, en een garantie dat een echt inlogprobleem nooit in stilte kan worden gemaskeerd door de fallbackmachinerie.

We testten het tegen een echte vijandige proxy

Een feature waarvan het hele doel is om vijandige netwerken te overleven, kan niet met unittests alleen worden gevalideerd — unittests hebben geen proxies. Voordat we hem inschakelden, draaiden we de echte app door een lokale reverse proxy die zo was geconfigureerd dat hij precies deed wat bedrijfsproxies doen: HTTPS doorsturen, WebSocket-upgrades afwijzen met een 403.

Het spoor in de logs is het bewijs: vier geblokkeerde WebSocket-pogingen, de uitputtingssignatuur herkend, de automatische overschakeling naar het HTTPS-transport, en daarna een gezonde transcriptiesessie van 96 seconden over puur HTTPS — 66 transcriptsegmenten, nul drops. De failover werkt omdat we hem hebben zien overschakelen.

Drie overdraagbare lessen

1. "Het werkt op wispelturige wifi" en "het werkt achter een vijandige proxy" zijn verschillende garanties. De ene heeft herverbinding nodig; de andere een ander transport. Ze op één hoop gooien laat een hele populatie bedrijfsgebruikers in stilte kapot.
2. Je foutclassificatie kan je eigen feature voor zichzelf verbergen. Een regel die 99% van de tijd klopt (403 = fatale auth) was precies fout voor de 1% waarvoor deze feature bestond. Als je een fallback toevoegt, audit dan of de triggerconditie de fallback überhaupt kan bereiken.
3. Test de tegenstander, niet alleen het gelukkige pad. De enige eerlijke test van "overleeft een WebSocket-blokkerende proxy" is een WebSocket-blokkerende proxy. Wij bouwden er een.

GeekBye v2.0.8 leverde de HTTPS-fallback uit, flag-gated en gevalideerd. Voor het betrouwbaarheidswerk waar hij naast staat, zie waarom je AI-notulist stopt bij slechte wifi, en voor de aangrenzende releases in deze serie, waarom je AI-notulist midden in een meeting stopt met opnemen (v2.0.9) en waarom AI-transcriptie technische termen verkeerd verstaat (v2.0.11).