⚠️ Uso de clases estáticas (Wsd, Settings.Current) y problemas de concurrencia en escenarios multiusuario / serverless

[andreami85]

Hola equipo de VeriFactu,

estoy integrando la librería en un entorno Azure Functions multi-tenant, donde varios usuarios pueden enviar facturas electrónicas al mismo tiempo.

He visto que tanto Wsd como Settings.Current son clases estáticas y mantienen el estado de forma global en todo el proceso. Esto genera varios problemas en escenarios con concurrencia:

Si una petición establece CertificateThumbprint, CertificatePath o directamente Wsd.Certificate, esos valores se aplican a todas las demás peticiones que se estén procesando en paralelo.

De esta forma, diferentes usuarios pueden “pisarse” la configuración del certificado y producir envíos incorrectos.

En entornos serverless (Functions, Kubernetes, microservicios) esto es especialmente crítico, porque una misma instancia atiende múltiples solicitudes simultáneas.

Workarounds actuales

Serializar el acceso con un SemaphoreSlim global: funciona, pero limita el rendimiento porque sólo permite un envío a la vez por instancia.

Ejecutar un proceso externo (runner) por cada petición: evita el estado compartido, pero añade complejidad de despliegue.

Propuesta de mejora

Sería muy útil disponer de un cliente instanciable y aislado (por ejemplo WsdClient) que reciba un objeto de configuración con el certificado y los parámetros necesarios, en lugar de depender de Settings.Current y Wsd estáticos.

Un ejemplo de uso podría ser:

var options = new WsdOptions {
    Environment = "Sandbox",
    Certificate = new X509Certificate2(pfxBytes, password,
        X509KeyStorageFlags.EphemeralKeySet | X509KeyStorageFlags.Exportable)
};
var client = new WsdClient(options);
var result = await client.SendInvoiceAsync(invoice);

De esta manera:

Cada petición tendría su propia configuración y certificado, sin interferir con otras.

La librería sería thread-safe y más adecuada para entornos cloud.

Se podría mantener compatibilidad: la API estática actual (Wsd, Settings.Current) simplemente delegaría a este nuevo cliente.

Pregunta

¿Estáis abiertos a aceptar una PR en esta dirección?
Mi idea sería añadir WsdOptions + WsdClient (instanciable) manteniendo las clases estáticas como “shim” para no romper la compatibilidad.

Esto facilitaría mucho la integración en plataformas multiusuario y serverless.

¡Gracias por vuestro trabajo en la librería! 🙏

[mdiago]

Hola @andreami85 ,

Muchas gracias por el análisis tan detallado y por compartir tu experiencia de integración en Azure Functions 👏.

Coincidimos plenamente en que escenarios multi-tenant y serverless requieren un diseño thread-safe y sin estado global compartido. Tu propuesta de incorporar un WsdClient instanciable junto con un objeto WsdOptions, manteniendo las clases estáticas como shim para no romper compatibilidad, nos parece una línea de mejora muy interesante.

Desde el equipo de VeriFactu estamos abiertos a cualquier mejora que aporte valor a la comunidad y agradecemos especialmente este tipo de colaboraciones.

Por supuesto, estamos encantados de recibir una PR en esta dirección, y nos comprometemos a revisarla con detalle. Seguro que facilitará mucho la integración en entornos multiusuario y cloud.

¡Gracias de nuevo por tu aportación y por confiar en la librería! 🙌