Firebase Admin Node httpAgent: tarpinio serverio aprėptis pagal paslaugą
Nustatykite, kurios Firebase Admin Node operacijos naudoja sukonfigūruotą HTTP agentą, prieš manydami, kad visas SDK srautas eina per tą patį tarpinį serverį.
Autentifikavimo iškvietimas veikia per tarpinį serverį, bet duomenų bazės ryšys nepavyksta. Firebase programoje tai gali būti transporto skirtumas, o ne periodiškai sutrikantis tarpinis serveris.
Admin Node SDK programos parinktis httpAgent taikoma paslaugoms, kurios atlieka REST iškvietimus, įskaitant Auth ir Messaging. Jos dokumentuota apimtis neapima Realtime Database ir Firestore. Kredencialų objektai taip pat turi savo agento konfigūraciją per atitinkamus kredencialų fabriko metodus.
| Nepavykstanti operacija | Konfigūracija, kurią reikia patikrinti |
|---|---|
| Admin REST paslaugos iškvietimas | Programos HTTP agentas |
| Kredencialo žetono gavimas | Kredencialo objekto HTTP konfigūracija |
| Duomenų bazės ryšys | Duomenų bazės kliento savoji transporto parama |
Štai kodėl agento pridėjimas inicijuojant negali garantuoti, kad kiekvienas vėlesnis ryšys eis tuo pačiu keliu. Užrašykite nepavykstančią paslaugą ir paskirties vietą prieš keisdami konfigūraciją, kuri jau veikia kitai paslaugai.
Senos diskusijos taip pat painioja Firebase komandų eilutės įrankį su programų SDK. CLI pataisa, skirta skaityti http_proxy, neįrodo, kad duomenų bazės klientas jūsų Node procese naudoja tą pačią parinktį.
Naudokite palaikomą konfigūracijos sąsają transportui, kurio jums tikrai reikia. Įterptosios WebSocket priklausomybės lopymas gali atrodyti, kad paveikia vieną ryšį, tuo tarpu kitas kelias lieka nepakitęs, ir apsunkina būsimo priklausomybių atnaujinimo supratimą.