Livetransskription når firewallen blokerer WebSockets

Der findes en bestemt, vanvittigt frustrerende måde for livetransskription at fejle på et virksomhedsnetværk. Din Wi-Fi er fin. HTTPS virker — du kan indlæse et hvilket som helst websted. Men livetransskription bare... starter ikke, og intet fortæller dig hvorfor.

Synderen er en klasse af virksomhedsproxyer, der tillader almindelig HTTPS-trafik, men blokerer WebSocket-opgraderingen — håndtrykket, der forvandler en HTTPS-forbindelse til den vedvarende, tovejskanal, som livetransskription har brug for. For proxyen ligner en WebSocket en uovervåget tunnel ud af netværket, så den dræber den. For dig er transskriptionen lydløst i stykker.

GeekBye v2.0.8 tilføjede en automatisk fallback til præcis dette — og at bygge den gravede en bug frem, der ville have fået hele funktionen til ikke at gøre noget.

Hvorfor en fallback, ikke bare et nyt forsøg

Vi håndterer allerede ustabile netværk. Hvis din forbindelse falder ud midt i en session, genopretter GeekBye med backoff og buffer dit lyd, så intet går tabt — det er en separat funktion, der dækkes i hvorfor din AI-notetager stopper på dårlig Wi-Fi.

Men en blokeret WebSocket er ikke en ustabil forbindelse. At prøve den samme WebSocket igen mod en proxy, der afviser WebSockets, fejler på samme måde hver gang, for evigt. Den eneste løsning er en anden transport — en, der ligner den almindelige HTTPS, proxyen allerede tillader.

Så v2.0.8 falder tilbage på en ren HTTPS-transport over det samme autentificerede endpoint:

• Ned (transskriptioner tilbage til dig): server-sent events — et langlivet HTTPS-svar, som proxyen ser som en almindelig streamet download.
• Op (dit lyd ud): buntede POST-anmodninger, hver bærer et lydsegment med et sekvensnummer, så serveren kan samle dem i rækkefølge, selv hvis netværket omorganiserer dem.

Ingen vedvarende socket, intet der ligner en tunnel — bare HTTPS-anmodninger og -svar. Hvis en proxy lader dig bruge et websted, tillader den dette.

Buggen, der ville have skibet en død funktion

Her er den del, der er værd at læse. Fallbacken skal udløses, når WebSocket-forbindelsen udtømmer sine forsøg med en signatur for blokeret transport — hvert forsøg fejler på opgraderingen, intet autentificerings- eller kvoteproblem, mindst ét proxyformet afslag. En proxy, der blokerer en WebSocket, svarer typisk på opgraderingen med en HTTP 403 Forbidden eller 407.

Problemet: vores forbindelseskode havde allerede en regel om, at en 403 betyder fatal autentificeringsfejl — stop, vis den til brugeren, prøv ikke igen. Hvilket er korrekt næsten alle steder. Men det betød, at 403'en fra en blokerende proxy — præcis det signal, der burde have udløst fallbacken — i stedet blev kastet som en fatal fejl før fallback-logikken nogensinde kunne køre. Kun et råt forbindelsestab (en 1006-lukning) faldt igennem til fallbacken. Så funktionen ville have virket for det sjældne tilfælde og lydløst fejlet for sit faktiske primære mål: virksomhedsproxyen.

Vi fangede dette, mens vi hærdede releasen, ikke i produktion. Fixet: en 403/407 på WebSocket-opgraderingsbenet behandles nu som genoprettelig, så forbindelsesloopet kan udtømmes ned i fallbacken — mens en ægte autentificeringsfejl (som ankommer anderledes, efter at opgraderingen er lykkedes) stadig fejler hurtigt, præcis som før. En regressionstest fastnagler nu forskellen: en blokeret proxys 403 skal falde tilbage; en ægte auth-403 må ikke.

Resten af hærdningen fulgte den samme paranoide linje: en timeout på hver upstream-POST, så en proxy, der accepterer en anmodning, men aldrig svarer, ikke kan stalle lydstrømmen, og en garanti for, at et ægte login-problem aldrig lydløst kan maskeres af fallback-maskineriet.

Vi testede det mod en rigtig fjendtlig proxy

En funktion, hvis hele formål er at overleve fjendtlige netværk, kan ikke valideres med enhedstest alene — enhedstest har ingen proxyer. Før vi aktiverede den, kørte vi den faktiske app gennem en lokal reverse proxy konfigureret til at gøre præcis, hvad virksomhedsproxyer gør: videresende HTTPS, afvise WebSocket-opgraderinger med en 403.

Sporet i logfilerne er kvitteringen: fire blokerede WebSocket-forsøg, den genkendte udtømmelsessignatur, det automatiske skift til HTTPS-transporten, og derefter en sund 96-sekunders transskriptionssession over ren HTTPS — 66 transskriptionssegmenter, nul udfald. Failoveren virker, fordi vi så den failove.

Tre overførbare lektioner

1. "Det virker på ustabil Wi-Fi" og "det virker bag en fjendtlig proxy" er forskellige garantier. Den ene kræver genoprettelse; den anden kræver en anden transport. At blande dem sammen efterlader en hel befolkning af virksomhedsbrugere lydløst i stykker.
2. Din fejlklassificering kan skjule din egen funktion for sig selv. En regel, der er korrekt 99 % af tiden (403 = fatal auth), var præcis forkert for de 1 %, denne funktion eksisterede for at betjene. Når du tilføjer en fallback, så gennemgå, om udløsningsbetingelsen overhovedet kan nå fallbacken.
3. Test modstanderen, ikke bare den lykkelige vej. Den eneste ærlige test af "overlever en WebSocket-blokerende proxy" er en WebSocket-blokerende proxy. Vi byggede en.

GeekBye v2.0.8 skibede HTTPS-fallbacken flagstyret og valideret. For det pålidelighedsarbejde, den står ved siden af, se hvorfor din AI-notetager stopper på dårlig Wi-Fi, og for de nærliggende releases i denne serie, hvorfor din AI-notetager stopper med at optage midt i mødet (v2.0.9) og hvorfor AI-transskription hører tekniske termer forkert (v2.0.11).