Better Auth 1.7 rompe los accesos por un cambio silencioso en la clave de cuentas
La actualización de Better Auth modifica la clave de las cuentas y deja sin acceso a los usuarios existentes; el fallo no aparece en los registros.
La biblioteca de autenticación Better Auth ha sacado la versión 1.7 y el cambio ya ha roto los accesos en producción. Quien la actualizó se encontró con que las cuentas existentes desaparecían: el inicio de sesión respondía "no se ha encontrado ninguna cuenta para este nombre", pero no había rastro del fallo ni en los registros ni en las alertas.
Qué ha cambiado
Better Auth 1.7 modifica el criterio con el que identifica las cuentas. Antes usaba el campo providerId y ahora necesita la combinación de issuer y accountId. Eso implica que la tabla Account de las bases de datos existentes se queda sin la columna issuer, obligatoria desde esta versión. Las filas antiguas no tienen ese valor y no casan con ninguna búsqueda. El resultado es un emparejamiento vacío: no se lanza ninguna excepción, simplemente no se devuelve nada. Es la situación que ha relatado un administrador después de resolver la incidencia.
La reparación pasa por una migración manual de la base de datos. Hay que añadir la columna issuer como nullable, rellenarla en función del proveedor: local:credential para el usuario con email y contraseña, y local:oauth: seguido del providerId para OAuth. Después hay que fijarla como NOT NULL y crear un índice único sobre issuer y accountId. No hay una migración automática que realice esos pasos, o al menos no se ejecutó en este caso.
Lo que deja en evidencia
Lo más llamativo no es la ruptura en sí, sino cómo se manifestó. El sistema parecía sano: sin errores, sin alertas, sin señales en los registros. Los primeros en avisar fueron los clientes, con sus tickets de soporte. Ese es un punto ciego habitual de las dependencias de terceros: una biblioteca cambia su comportamiento interno y la integración falla de forma silenciosa.
El propio afectado plantea una pregunta pertinente: ¿cómo se entera uno de un fallo que no genera ningún error? Los monitores de registros y de tiempo de ejecución no suelen detectar una respuesta vacía que no lanza una excepción. Una alternativa que sugiere es montar un "canario" de acceso: una cuenta de prueba que intente autenticarse cada pocos minutos y salte una alerta si falla. También se pregunta si conviene vigilar los anuncios de cambios incompatibles de las dependencias antes de que lleguen a producción.
La incidencia se ha resuelto con el parche manual, pero deja una lección práctica: cuando una biblioteca cambia la forma de guardar sus propios datos, la actualización deja de ser un simple cambio de versión. Sin una comprobación periódica del flujo real de acceso, el aviso llega demasiado tarde, normalmente con el cliente al otro lado del ticket.
