Livetranskripsjon når brannmuren blokkerer WebSockets

Det finnes en bestemt, vanvittig frustrerende måte for livetranskripsjon å feile på et bedriftsnettverk. Wi-Fi-en din er grei. HTTPS fungerer — du kan laste hvilken som helst nettside. Men livetranskripsjon bare... starter ikke, og ingenting forteller deg hvorfor.

Synderen er en klasse av bedriftsproxyer som tillater vanlig HTTPS-trafikk, men blokkerer WebSocket-oppgraderingen — håndtrykket som forvandler en HTTPS-tilkobling til den vedvarende, toveis kanalen som livetranskripsjon trenger. For proxyen ser en WebSocket ut som en uovervåket tunnel ut av nettverket, så den dreper den. For deg er transkripsjonen stille ødelagt.

GeekBye v2.0.8 la til en automatisk fallback for akkurat dette — og å bygge den gravde frem en bug som ville ha fått hele funksjonen til å ikke gjøre noe.

Hvorfor en fallback, ikke bare et nytt forsøk

Vi håndterer allerede ustabile nettverk. Hvis tilkoblingen din faller ut midt i en økt, kobler GeekBye seg til igjen med backoff og buffrer lyden din, så ingenting går tapt — det er en egen funksjon som dekkes i hvorfor AI-notatverktøyet ditt stopper på dårlig Wi-Fi.

Men en blokkert WebSocket er ikke en ustabil tilkobling. Å prøve den samme WebSocketen igjen mot en proxy som nekter WebSockets, feiler på samme måte hver gang, for alltid. Den eneste løsningen er en annen transport — en som ser ut som den vanlige HTTPS-en proxyen allerede tillater.

Så v2.0.8 faller tilbake på en ren HTTPS-transport over det samme autentiserte endepunktet:

• Ned (transkripsjoner tilbake til deg): server-sent events — et langlivet HTTPS-svar som proxyen ser på som en vanlig strømmet nedlasting.
• Opp (lyden din ut): buntede POST-forespørsler, hver bærer et lydsegment med et sekvensnummer, slik at serveren kan sette dem sammen i riktig rekkefølge selv om nettverket omorganiserer dem.

Ingen vedvarende socket, ingenting som ser ut som en tunnel — bare HTTPS-forespørsler og -svar. Hvis en proxy lar deg bruke en nettside, tillater den dette.

Buggen som ville ha sendt en død funksjon

Her er delen verdt å lese. Fallbacken skal utløses når WebSocket-tilkoblingen bruker opp forsøkene sine med en signatur for blokkert transport — hvert forsøk feiler på oppgraderingen, ingen autentiserings- eller kvoteproblemer, minst én proxyformet avvisning. En proxy som blokkerer en WebSocket, svarer typisk på oppgraderingen med en HTTP 403 Forbidden eller 407.

Problemet: tilkoblingskoden vår hadde allerede en regel om at en 403 betyr fatal autentiseringsfeil — stopp, vis den til brukeren, ikke prøv igjen. Noe som er riktig nesten overalt. Men det betydde at 403-en fra en blokkerende proxy — nøyaktig det signalet som skulle ha utløst fallbacken — i stedet ble kastet som en fatal feil før fallback-logikken noen gang kunne kjøre. Bare et rått tilkoblingsbrudd (en 1006-lukking) falt gjennom til fallbacken. Så funksjonen ville ha virket for det sjeldne tilfellet og stille feilet for sitt faktiske primære mål: bedriftsproxyen.

Vi fanget dette mens vi herdet lanseringen, ikke i produksjon. Fiksen: en 403/407 på WebSocket-oppgraderingsbenet behandles nå som gjenopprettelig, slik at tilkoblingsløkken kan brukes opp ned i fallbacken — mens en genuin autentiseringsfeil (som ankommer annerledes, etter at oppgraderingen har lyktes) fortsatt feiler raskt, akkurat som før. En regresjonstest fester nå forskjellen: en blokkert proxys 403 må falle tilbake; en ekte auth-403 må ikke.

Resten av herdingen fulgte den samme paranoide linjen: en timeout på hver oppstrøms-POST slik at en proxy som godtar en forespørsel, men aldri svarer, ikke kan stanse lydstrømmen, og en garanti for at et ekte innloggingsproblem aldri stille kan maskeres av fallback-maskineriet.

Vi testet det mot en ekte fiendtlig proxy

En funksjon hvis hele hensikt er å overleve fiendtlige nettverk, kan ikke valideres med enhetstester alene — enhetstester har ingen proxyer. Før vi aktiverte den, kjørte vi selve appen gjennom en lokal reverse proxy konfigurert til å gjøre nøyaktig det bedriftsproxyer gjør: videresende HTTPS, avvise WebSocket-oppgraderinger med en 403.

Sporet i loggene er kvitteringen: fire blokkerte WebSocket-forsøk, den gjenkjente utmattelsessignaturen, det automatiske byttet til HTTPS-transporten, og deretter en frisk 96-sekunders transkripsjonsøkt over ren HTTPS — 66 transkripsjonssegmenter, null bortfall. Failoveren fungerer fordi vi så den failove.

Tre overførbare lærdommer

1. "Det virker på ustabil Wi-Fi" og "det virker bak en fiendtlig proxy" er forskjellige garantier. Den ene trenger gjenoppkobling; den andre trenger en annen transport. Å blande dem sammen etterlater en hel populasjon av bedriftsbrukere stille ødelagt.
2. Feilklassifiseringen din kan skjule din egen funksjon for seg selv. En regel som er riktig 99 % av tiden (403 = fatal auth), var akkurat feil for de 1 % denne funksjonen eksisterte for å betjene. Når du legger til en fallback, gå gjennom om utløsningsbetingelsen i det hele tatt kan nå fallbacken.
3. Test motstanderen, ikke bare den lykkelige veien. Den eneste ærlige testen av "overlever en WebSocket-blokkerende proxy" er en WebSocket-blokkerende proxy. Vi bygde en.

GeekBye v2.0.8 sendte HTTPS-fallbacken flaggstyrt og validert. For pålitelighetsarbeidet den står ved siden av, se hvorfor AI-notatverktøyet ditt stopper på dårlig Wi-Fi, og for nabolanseringene i denne serien, hvorfor AI-notattakeren din slutter å ta opp midt i møtet (v2.0.9) og hvorfor AI-transkripsjon hører tekniske termer feil (v2.0.11).