Relatório de incidente para o erro 500 inesperado retornado pelos 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 erro interno do servidor 500 proveniente dos serviços de autenticação.
Durante uma recente implementação no Cloud, uma alteração na estrutura da base de dados causou a falha da API de experiência de login durante a transição entre os ambientes de staging e produção.
Estamos atualmente a desenvolver uma nova funcionalidade chamada "Traga a sua IU", que permite aos utilizadores personalizar a experiência de login do Logto com as suas próprias páginas web. Esta funcionalidade requer uma nova coluna na tabela sign-in-exp para armazenar a configuração personalizada da IU.
Devido a algumas alterações de requisitos durante o desenvolvimento, o lançamento da funcionalidade foi adiado, mas a primeira parte da alteração da estrutura já tinha sido implementada na produção há várias semanas, apesar de ainda não estar em uso. Uma atualização da coluna da base de dados foi introduzida neste PR.
Infelizmente, esta alteração não foi compatível com versões anteriores, causando falhas nas solicitações API do código antigo ao comunicar com a nova base de dados.
Ao implementar uma nova versão do Logto Cloud, primeiro implementamos no ambiente de staging e depois trocamos os ambientes de staging e produção. O processo é o seguinte:
No entanto, ambos os ambientes partilham a mesma base de dados, e todo o processo leva tempo. Por isso, na janela de tempo entre a atualização da base de dados e a troca dos ambientes, os utilizadores que estavam online permaneceram no ambiente de produção com o código antigo mas tentavam comunicar-se com a nova base de dados.
Esta foi a causa raiz do incidente e o motivo pelo qual foi resolvido automaticamente em 35 minutos.
TEMOS uma tarefa de CI para verificar a compatibilidade com versões anteriores das alterações na base de dados. No entanto, anteriormente não era obrigatório passar na verificação de CI antes de fazer o merge do PR. Isto porque, na maioria das vezes, a fase de desenvolvimento é geralmente curta, dentro de poucas sprints, e a primeira e a segunda parte das alterações na estrutura geralmente estão incluídas na mesma fase de lançamento.
Desta vez, o lançamento da funcionalidade foi adiado, espalhando as alterações na estrutura em duas versões. O desenvolvedor presumiu que a falha de CI era esperada e informou os revisores que isso não deveria impedir o merge do PR.
Houve definitivamente uma falha de comunicação, e, finalmente, o PR foi feito merge sem fornecer qualquer suporte necessário de compatibilidade com versões anteriores.