Firebase Admin Node httpAgent: cobertura del proxy por servicio
Determine qué operaciones de Firebase Admin Node usan el agente HTTP configurado antes de suponer que todo el tráfico del SDK utiliza el mismo proxy.
Una llamada de autenticación funciona a través del proxy, pero una conexión a la base de datos falla. En una aplicación de Firebase, eso puede ser una diferencia de transporte y no un proxy intermitente.
La opción de aplicación httpAgent del Admin Node SDK se aplica a los servicios que realizan llamadas REST, incluidos Auth y Messaging. Su alcance documentado excluye Realtime Database y Firestore. Los objetos de credenciales también tienen su propia configuración de agente mediante los métodos de fábrica de credenciales correspondientes.
| Operación que falla | Configuración que revisar |
|---|---|
| Una llamada a un servicio REST de Admin | El agente HTTP de la aplicación |
| Obtener un token de credencial | La configuración HTTP del objeto de credencial |
| Una conexión a la base de datos | El soporte de transporte propio del cliente de base de datos |
Por eso añadir un agente en la inicialización no puede certificar que todas las conexiones posteriores sigan la misma ruta. Anote el servicio y el destino que fallan antes de cambiar una configuración que ya funciona para otro servicio.
Los debates antiguos también mezclan la herramienta de línea de comandos de Firebase con los SDK de aplicaciones. Una corrección de la CLI para leer http_proxy no demuestra que un cliente de base de datos dentro de su proceso de Node use esa misma opción.
Utilice la interfaz de configuración admitida para el transporte que realmente necesita. Parchear una dependencia de WebSocket anidada puede parecer que afecta a una conexión mientras deja otra ruta sin cambios, y dificulta razonar sobre una futura actualización de dependencias.