Estaba registrado antes que Tenant/License, así que su cronómetro arrancaba
DESPUÉS de que ambos ya habían corrido — el Duration: en los logs nunca
incluyó el costo de verify-license/auth-me contra el Hub, dando la falsa
impresión de que todo respondía en 2-5ms. Reordenado para que sea el más
externo de los tres (CORS sigue siendo el más externo de todos).
Bug preexistente: LicenseValidationMiddleware se registraba después de
TenantMiddleware, pero add_middleware() de Starlette invierte el orden de
ejecución (el último registrado corre primero) — así que License corría ANTES
que Tenant en la práctica, contradiciendo el comentario en middleware.py que
asumía lo contrario ("TenantMiddleware corre antes... dejó tenant en
user_info").
Efecto real: request.state.user_info nunca existía cuando License intentaba
usarlo como fallback para tenant_override → el caché de licencia (agregado en
a1bbb6b1) nunca podía activarse para requests sin X-Tenant-Override
header/cookie explícito. Confirmado en vivo contra el Hub real
(workspace.aduanasoft.com): verify-license se repetía en cada request pese al
caché. Con el orden corregido, la segunda llamada dentro del TTL ya no golpea
al Hub.
Cada navegación al dashboard disparaba verify-license y auth/me contra el Hub sin
ningún caché, sumando 1-6s por llamada del lado del Hub a cada request.
- security.py: token_cache TTL 60s→300s (el access token vive más que el TTL
anterior; cachear su verificación es seguro).
- middleware.py: nuevo _license_ok_cache (TTLCache, 300s) en
LicenseValidationMiddleware — SOLO cachea el camino "licencia válida" por
tenant_override; inválida/expirada/error nunca se cachea y siempre revalida
contra el Hub (fail-closed: el peor caso es que un tenant recién revocado siga
pasando hasta 5 min más, nunca al revés).
