Prepis naživo, keď firewall blokuje WebSockety

Existuje jeden konkrétny, k zúrivosti privádzajúci spôsob, akým prepis v reálnom čase zlyháva vo firemnej sieti. Vaše Wi-Fi je v poriadku. HTTPS funguje — dokážete načítať ľubovoľnú stránku. Ale prepis naživo jednoducho... nenaštartuje a nič vám nepovie prečo.

Vinníkom je trieda firemného proxy, ktoré prepúšťa bežnú HTTPS premávku, ale blokuje upgrade na WebSocket — handshake, ktorý mení HTTPS spojenie na trvalý, obojsmerný kanál, aký prepis v reálnom čase potrebuje. Pre proxy WebSocket vyzerá ako nemonitorovaný tunel von zo siete, tak ho zabije. Pre vás je prepis potichu rozbitý.

GeekBye v2.0.8 pridal automatický fallback presne na toto — a jeho stavba vyniesla na povrch bug, ktorý by celú funkciu nechal nič nerobiť.

Prečo fallback, a nie len opakovanie

Nestabilné siete už zvládame. Ak sa vám spojenie preruší uprostred relácie, GeekBye sa opätovne pripojí s backoffom a bufferuje vaše audio, aby sa nič nestratilo — to je samostatná funkcia popísaná v prečo váš AI zapisovač zlyháva na zlom Wi-Fi.

Ale zablokovaný WebSocket nie je nestabilné spojenie. Opakovanie toho istého WebSocketu proti proxy, ktoré WebSockety odmieta, zlyhá zakaždým rovnako, navždy. Jediná náprava je iný transport — taký, ktorý vyzerá ako obyčajné HTTPS, ktoré proxy už povoľuje.

Takže v2.0.8 sa prepne na čisto-HTTPS transport cez ten istý autentifikovaný endpoint:

• Dole (prepisy vracajúce sa k vám): server-sent events — dlho žijúca HTTPS odpoveď, ktorú proxy vidí ako obyčajné streamované sťahovanie.
• Hore (vaše audio idúce von): dávkované POST požiadavky, každá nesie kus audia s poradovým číslom, aby ich server dokázal poskladať v poradí, aj keď ich sieť preusporiada.

Žiadny trvalý socket, nič, čo vyzerá ako tunel — len HTTPS požiadavky a odpovede. Ak vám proxy dovolí používať stránku, dovolí aj toto.

Bug, ktorý by vydal mŕtvu funkciu

Tu je časť, ktorá stojí za prečítanie. Fallback sa má spustiť, keď WebSocket spojenie vyčerpá svoje pokusy so signatúrou zablokovaného transportu — každý pokus zlyhá na upgrade, žiaden problém s auth ani s limitom, aspoň jedno odmietnutie v tvare proxy. Proxy blokujúce WebSocket zvyčajne odpovie na upgrade HTTP 403 Forbidden alebo 407.

Problém: náš kód spojenia už mal pravidlo, že 403 znamená fatálnu chybu autentifikácie — zastav sa, ukáž ju používateľovi, neopakuj. Čo je takmer všade správne. Ale znamenalo to, že 403 od blokujúceho proxy — presne ten signál, ktorý mal spustiť fallback — sa namiesto toho vyhodilo ako fatálna chyba skôr, ako sa logika fallbacku vôbec mohla spustiť. Iba surové prerušenie spojenia (zatvorenie 1006) prepadlo ďalej do fallbacku. Takže funkcia by fungovala pre zriedkavý prípad a potichu by zlyhala pre svoj skutočný hlavný cieľ: firemné proxy.

Zachytili sme to pri kalení vydania, nie v produkcii. Oprava: 403/407 na upgrade nohe WebSocketu sa teraz považuje za zotaviteľné, aby sa cyklus spojenia mohol vyčerpať do fallbacku — zatiaľ čo skutočné zlyhanie autentifikácie (ktoré prichádza inak, po úspešnom upgrade) stále zlyháva rýchlo, presne ako predtým. Regresný test teraz pripína tento rozdiel: 403 od zablokovaného proxy musí prejsť na fallback; skutočné 403 auth nesmie.

Zvyšok kalenia šiel tou istou paranoidnou líniou: timeout na každom odchádzajúcom POST, aby proxy, ktoré požiadavku prijme, ale nikdy neodpovie, nemohlo zaseknúť audio prúd, a záruka, že skutočný problém s prihlásením nikdy nemôže byť potichu zamaskovaný mašinériou fallbacku.

Otestovali sme to proti skutočnému nepriateľskému proxy

Funkciu, ktorej celým zmyslom je prežiť nepriateľské siete, nemožno overiť len jednotkovými testami — jednotkové testy nemajú proxy. Pred zapnutím sme prehnali skutočnú aplikáciu cez lokálne reverse proxy nastavené robiť presne to, čo robia firemné proxy: prepúšťať HTTPS, odmietať upgrade WebSocketu s 403.

Stopa v logoch je potvrdenka: štyri zablokované pokusy WebSocketu, rozpoznaná signatúra vyčerpania, automatické prepnutie na HTTPS transport a potom zdravá 96-sekundová relácia prepisu cez čisté HTTPS — 66 segmentov prepisu, nula výpadkov. Failover funguje, lebo sme videli, ako sa prepne.

Tri prenosné ponaučenia

1. „Funguje na nestabilnom Wi-Fi" a „funguje za nepriateľským proxy" sú rozdielne záruky. Jedna potrebuje opätovné pripojenie; druhá potrebuje iný transport. Ich zamieňanie necháva celú populáciu firemných používateľov potichu rozbitú.
2. Vaša klasifikácia chýb môže skryť vašu vlastnú funkciu pred ňou samou. Pravidlo správne v 99% prípadov (403 = fatálny auth) bolo presne nesprávne pre to 1%, ktorému táto funkcia mala slúžiť. Keď pridávate fallback, preverte, či podmienka spustenia vôbec dokáže dosiahnuť fallback.
3. Testujte protivníka, nielen šťastnú cestu. Jediný čestný test „prežije proxy blokujúce WebSocket" je proxy blokujúce WebSocket. Postavili sme ho.

GeekBye v2.0.8 vydal HTTPS fallback za vlajkou a overený. O susediacej práci na spoľahlivosti si prečítajte prečo váš AI zapisovač zlyháva na zlom Wi-Fi, a o susedných vydaniach tejto série prečo váš AI zapisovač prestane nahrávať uprostred stretnutia (v2.0.9) a prečo AI transkripcia komolí technické termíny (v2.0.11).