Postmortem: oväntat 500-fel inträffade under användarinloggning
Incidentrapport för det oväntade 500-felet från autentiseringstjänster den 18 juli 2024.
Incidentrapport för det oväntade 500-felet från autentiseringstjänster den 18 juli 2024.
Den 18 juli 2024 drabbades Logto Cloud av ett servicestopp med 500 Internt serverfel från autentiseringstjänsterna.
Under en nyligen genomförd molndistribution orsakade en brytande ändring i databasschemat att API:et för inloggningsupplevelse misslyckades under övergången mellan staging- och produktionsmiljöer.
Vi utvecklar för närvarande en ny funktion som kallas "Bring your UI", som tillåter användare att anpassa Logtos inloggningsupplevelse med sina egna webbsidor. Denna funktion kräver en ny kolumn i tabellen sign-in-exp för att lagra den anpassade UI-konfigurationen.
På grund av vissa kravändringar under utvecklingen blev funktionslanseringen försenad, men den första delen av schemaändringen distribuerades redan till produktionen för flera veckor sedan, trots att den ännu inte används. En uppdatering av databasens kolumn introducerades i detta PR.
Tyvärr var denna ändring inte bakåtkompatibel, vilket orsakade att API-förfrågningar från den gamla koden misslyckades när de kommunicerade med den nya databasen.
När vi distribuerar en ny version av Logto Cloud, distribuerar vi den först till staging-miljön och byter sedan staging- och produktionsmiljöerna. Processen är som följer:
Emellertid delar båda miljöerna samma databas, och hela processen tar tid. Så i tidsfönstret mellan databasuppdateringen och miljöbytet, förblir onlineanvändare i produktionsmiljön med den gamla koden men försöker kommunicera med den nya databasen.
Detta var grundorsaken till incidenten och orsaken till att den automatiskt löstes på 35 minuter.
Vi har en CI-uppgift för att kontrollera bakåtkompatibiliteten för databasändringarna. Tidigare var det dock inte nödvändigt att klara CI-kontrollen innan sammanslagningen av PR. Detta beror på att utvecklingsfasen för det mesta är kort inom några sprinter, och den första och andra delen av schemaändringarna vanligtvis ingår i samma lanseringsfas.
Den här gången blev funktionslanseringen försenad och spred schemaändringarna över två lanseringar. Utvecklaren antog att CI-felet var förväntat och informerade granskarna om att det inte borde blockera PR från att slås samman.
Ett kommunikationsgap fanns definitivt också där, och slutligen slogs PR samman utan att ge nödvändigt bakåtkompatibilitetsstöd.