Informe del incidente sobre el error inesperado 500 devuelto por los servicios de autenticación el 18 de julio de 2024.
El 18 de julio de 2024, Logto Cloud experimentó una interrupción del servicio con un error 500 de servidor interno en los servicios de autenticación.
Durante un despliegue reciente en Cloud, un cambio que rompía la estructura de la base de datos causó que la API de experiencia de inicio de sesión fallara durante la transición entre los entornos de pruebas y producción.
Actualmente estamos desarrollando una nueva función llamada "Trae tu UI", que permite a los usuarios personalizar la experiencia de inicio de sesión de Logto con sus propias páginas web. Esta función requiere una nueva columna en la tabla sign-in-exp para almacenar la configuración de UI personalizada.
Debido a algunos cambios en los requisitos durante el desarrollo, el lanzamiento de la función se retrasó, pero la primera parte del cambio en la estructura de la base de datos ya se desplegó en producción hace varias semanas, a pesar de que aún no está en uso. Una actualización de la columna de la base de datos se introdujo en este PR.
Desafortunadamente, este cambio no era compatible hacia atrás, lo que causaba que las solicitudes de API del código antiguo fallaran al comunicarse con la nueva base de datos.
Al desplegar una nueva versión de Logto Cloud, primero la desplegamos en el entorno de pruebas y luego intercambiamos los entornos de pruebas y producción. El proceso es el siguiente:
Sin embargo, ambos entornos comparten la misma base de datos y todo el proceso lleva tiempo. Entonces, en la ventana de tiempo entre la actualización de la base de datos y el intercambio de entornos, los usuarios en línea permanecen en el entorno de producción con el código antiguo pero intentan comunicarse con la nueva base de datos.
Esta fue la causa raíz del incidente y la razón por la que se resolvió automáticamente en 35 minutos.
Sí TENEMOS una tarea de CI para verificar la compatibilidad hacia atrás de los cambios en la base de datos. Sin embargo, anteriormente no era necesario aprobar la verificación de CI antes de fusionar el PR. Esto se debe a que la mayor parte del tiempo la fase de desarrollo es usualmente corta, dentro de unas pocas sprints, y la primera y segunda parte de los cambios en la estructura de la base de datos generalmente se incluyen en la misma fase de lanzamiento.
Esta vez, el lanzamiento de la función se retrasó, extendiendo los cambios en la estructura de la base de datos a dos lanzamientos. El desarrollador asumió que la falla en el CI era esperada e informó a los revisores que no debería bloquear la fusión del PR.
Definitivamente hubo una brecha de comunicación y, finalmente, el PR se fusionó sin proporcionar el soporte necesario para la compatibilidad hacia atrás.