Rapporto sull'incidente relativo all'errore 500 imprevisto restituito dai servizi di autenticazione il 18 luglio 2024.
Il 18 luglio 2024, Logto Cloud ha subito un'interruzione del servizio con errore 500 del server interno dai servizi di autenticazione.
Durante un recente deployment di Cloud, un cambiamento radicale nello schema del database ha causato il fallimento dell'API di accesso durante la transizione tra gli ambienti di staging e produzione.
Attualmente stiamo sviluppando una nuova funzione chiamata "Bring your UI", che consente agli utenti di personalizzare l'esperienza di accesso di Logto con le loro pagine web. Questa funzione richiede una nuova colonna nella tabella sign-in-exp per memorizzare la configurazione dell'interfaccia utente personalizzata.
A causa di alcuni cambiamenti nei requisiti durante lo sviluppo, il rilascio della funzione è stato ritardato, ma la prima parte della modifica dello schema è stata già distribuita in produzione alcune settimane fa, nonostante non fosse ancora in uso. Un aggiornamento della colonna del database è stato introdotto in questa PR.
Sfortunatamente, questo cambiamento non era retrocompatibile, causando il fallimento delle richieste API dal vecchio codice quando comunicavano con il nuovo database.
Quando distribuiamo una nuova versione di Logto Cloud, la distribuiamo prima nell'ambiente di staging e poi scambiamo gli ambienti di staging e produzione. Il processo è il seguente:
Tuttavia, entrambi gli ambienti condividono lo stesso database e l'intero processo richiede tempo. Quindi, nella finestra temporale tra l'aggiornamento del database e lo scambio degli ambienti, gli utenti online rimangono nell'ambiente di produzione con il vecchio codice ma tentano di comunicare con il nuovo database.
Questa è stata la causa principale dell'incidente e il motivo per cui è stato automaticamente risolto in 35 minuti.
Abbiamo UN task CI per verificare la retrocompatibilità delle modifiche al database. Tuttavia, in precedenza non era richiesto superare il controllo CI prima di unire la PR. Questo perché la fase di sviluppo è solitamente breve, entro pochi sprint, e la prima e la seconda parte delle modifiche allo schema sono generalmente incluse nella stessa fase di rilascio.
Questa volta, il rilascio della funzione è stato ritardato, distribuendo le modifiche allo schema su due rilasci. Lo sviluppatore ha supposto che il fallimento del CI fosse previsto e ha informato i revisori che non doveva bloccare la PR dall'unione.
C'era sicuramente un gap di comunicazione, e infine la PR è stata fusa senza fornire alcun supporto necessario per la retrocompatibilità.