Variables de entorno
createArcaClient() descubre los campos que faltan con las mismas reglas que
createArcaClientConfigFromEnv(). Los campos explícitos tienen prioridad y
process.env no se modifica.
Para loguear sin tocar el código, definí
ARCA_LOG_LEVEL en debug, info,
warn o error.
Opciones de createArcaClient()
Pasale un objeto de configuración a createArcaClient:
Stores de sesión WSAA
Por defecto, los tickets de login de WSAA se guardan solo en el proceso actual. Eso mantiene los scripts y las apps de un solo proceso sin configuración:store configurado provee tickets WSAA persistentes de forma automática. Un
wsaaSessionStore explícito sigue soportado y tiene prioridad, solo para los
tickets.
advisory locks de Postgres, bloqueos de Redis o un mecanismo equivalente.
Para pruebas y coordinación local a través de un objeto compartido, el paquete
también exporta createMemoryWsaaSessionStore().
Logs
El nivel mínimo por defecto eswarn. En debug, el SDK loguea los requests
SOAP, los tiempos de respuesta, el origen del login WSAA (cached o fresh) y
los reintentos.
(level, message, ...args):
logger: { disabled: true }.
Reintentos y límites de tiempo
Los reintentos de transporte configurados se aplican solo aArcaTransportError: límites de tiempo, fallas de conexión y respuestas HTTP de error
que no son XML. Las respuestas XML, incluidos los errores SOAP con HTTP 500, se
parsean y se exponen como errores de SOAP o de servicio en vez de reintentarse
a ciegas.
Aparte, las operaciones autenticadas de conveniencia de WSFE y WSMTXCA pueden
hacer un reintento con refresco forzado, solo después de un
ArcaAuthenticationError. Los límites de tiempo, la pérdida de conexión, el SOAP
inválido, la evidencia incompleta, la evidencia contradictoria y los rechazos
genéricos de servicio nunca habilitan ese camino de recuperación.
wsfe.issue() y wsmtxca.issue() siempre hacen un único intento de
autorización, y cada intento SOAP de autorización va con los reintentos de
transporte en cero.