Incidentrapport voor de onverwachte 500 fout geretourneerd door authenticatiediensten op 18 juli 2024.
Op 18 juli 2024 ondervond Logto Cloud een dienstonderbreking met een 500 Interne serverfout van de authenticatiediensten.
Tijdens een recente Cloud-implementatie veroorzaakte een ingrijpende wijziging in het databaseschema dat de API voor de aanmeldingservaring faalde tijdens de overgang tussen de staging- en productieomgevingen.
We ontwikkelen momenteel een nieuwe functie genaamd "Breng je UI", waarmee gebruikers de Logto-aanmeldingservaring kunnen aanpassen met hun eigen webpagina's. Deze functie vereist een nieuwe kolom in de sign-in-exp tabel om de aangepaste UI-configuratie op te slaan.
Vanwege enkele wijzigende vereisten tijdens de ontwikkeling werd de functie-release vertraagd, maar het eerste deel van de schemawijziging werd al enkele weken geleden naar de productie gebracht, hoewel het nog niet in gebruik was. Een update van de databasekolom werd geïntroduceerd in deze PR.
Helaas was deze wijziging niet achterwaarts compatibel, waardoor API-verzoeken van de oude code faalden bij communicatie met de nieuwe database.
Bij het implementeren van een nieuwe versie van Logto Cloud implementeren we deze eerst naar de staging-omgeving en wisselen vervolgens de staging- en productieomgevingen. Het proces is als volgt:
Echter, beide omgevingen delen dezelfde database, en het hele proces neemt tijd in beslag. Dus in het tijdsvenster tussen de database-update en het wisselen van omgevingen blijven online gebruikers in de productieomgeving met de oude code maar proberen te communiceren met de nieuwe database.
Dit was de oorzaak van het incident en de reden waarom het automatisch werd opgelost in 35 minuten.
We hebben WEL een CI-taak om de achterwaartse compatibiliteit van de databasewijzigingen te controleren. Echter, eerder was het niet verplicht om de CI-controle te halen voordat de PR werd samengevoegd. Dit komt omdat de ontwikkelingsfase meestal kort is binnen enkele sprints, en het eerste en tweede deel van de schemawijzigingen meestal worden opgenomen in dezelfde releasefase.
Deze keer werd de functie-release vertraagd, waardoor de schemawijzigingen over twee releases werden verspreid. De ontwikkelaar ging ervan uit dat de CI-fout werd verwacht en informeerde de beoordelaars dat het de PR niet zou moeten blokkeren voor samenvoeging.
Er was zeker een communicatiekloof aanwezig en uiteindelijk werd de PR samengevoegd zonder de benodigde achterwaartse compatibiliteitsondersteuning te bieden.