Relatório de incidente para o erro 500 inesperado retornado dos serviços de autenticação em 18 de julho de 2024.
Em 18 de julho de 2024, o Logto Cloud sofreu uma interrupção de serviço com o erro 500 de servidor interno nos serviços de autenticação.
Durante uma implantação recente do Cloud, uma mudança impactante no esquema do banco de dados fez com que a API de experiência de login falhasse durante a transição entre os ambientes de staging e produção.
Atualmente, estamos desenvolvendo um novo recurso chamado "Traga sua UI", que permite que os usuários personalizem a experiência de login do Logto com suas próprias páginas web. Esse recurso requer uma nova coluna na tabela sign-in-exp para armazenar a configuração da UI personalizada.
Devido a algumas mudanças de requisitos durante o desenvolvimento, o lançamento do recurso foi atrasado, mas a primeira parte da mudança no esquema já havia sido implantada na produção há várias semanas, apesar de ainda não estar em uso. Uma atualização da coluna do banco de dados foi introduzida neste PR.
Infelizmente, essa mudança não era retrocompatível, fazendo com que as requisições de API do código antigo falhassem ao se comunicar com o novo banco de dados.
Ao implantar uma nova versão do Logto Cloud, primeiro a implantamos no ambiente de staging e, em seguida, trocamos os ambientes de staging e produção. O processo é o seguinte:
No entanto, ambos os ambientes compartilham o mesmo banco de dados, e todo o processo leva tempo. Então, no intervalo de tempo entre a atualização do banco de dados e a troca de ambiente, os usuários online permanecem no ambiente de produção com o código antigo, mas tentam se comunicar com o novo banco de dados.
Essa foi a causa raiz do incidente e a razão pela qual ele foi resolvido automaticamente em 35 minutos.
Nós TEMOS uma tarefa de CI para verificar a retrocompatibilidade das mudanças no banco de dados. No entanto, anteriormente não era obrigatório passar na verificação de CI antes de mesclar o PR. Isso ocorre porque, na maioria das vezes, a fase de desenvolvimento normalmente é curta dentro de alguns sprints, e a primeira e a segunda parte das mudanças no esquema geralmente são incluídas na mesma fase de lançamento.
Desta vez, o lançamento do recurso foi atrasado, espalhando as mudanças no esquema por dois lançamentos. O desenvolvedor assumiu que a falha no CI era esperada e informou os revisores que isso não deveria impedir a mesclagem do PR.
Houve definitivamente uma lacuna de comunicação também, e finalmente o PR foi mesclado sem fornecer qualquer suporte necessário à retrocompatibilidade.