Ölümden Sonra: Kullanıcı oturumu açarken beklenmedik bir 500 hatası meydana geldi
18 Temmuz 2024 tarihinde kimlik doğrulama hizmetlerinden dönülen beklenmedik 500 hatasıyla ilgili olay raporu.
18 Temmuz 2024 tarihinde kimlik doğrulama hizmetlerinden dönülen beklenmedik 500 hatasıyla ilgili olay raporu.
18 Temmuz 2024 tarihinde, Logto Cloud kimlik doğrulama hizmetlerinden 500 Internal Server Error hatasıyla bir hizmet kesintisi yaşandı.
Son Cloud dağıtımı sırasında, veritabanı şeması ile ilgili bir kırılma değişikliği, aşama ve üretim ortamları arasındaki geçiş sırasında oturum açma deneyimi API'sinin başarısız olmasına neden oldu.
Şu anda kullanıcıların kendi web sayfalarıyla Logto oturum açma deneyimini özelleştirmelerine olanak tanıyan "Kendi UI'ni Getir" adlı yeni bir özellik geliştiriyoruz. Bu özellik, özel UI yapılandırmasını depolamak için sign-in-exp tablosuna yeni bir sütun eklenmesini gerektiriyor.
Geliştirme sırasında bazı gereksinim değişiklikleri nedeniyle özellik yayını ertelendi, ancak şema değişikliğinin ilk kısmı birkaç hafta önce üretime dağıtılmıştı, henüz kullanılmıyor olmasına rağmen. Bir veritabanı sütunu güncellemesi, bu PR'de tanıtıldı.
Maalesef, bu değişiklik geriye dönük uyumlu değildi ve eski koddan gelen API isteklerinin yeni veritabanı ile iletişim kurarken başarısız olmasına neden oldu.
Logto Cloud'un yeni bir sürümünü dağıtırken, önce onu aşama ortamına dağıtırız ve ardından aşama ve üretim ortamlarını değiştiririz. Süreç şu şekildedir:
Ancak, her iki ortam da aynı veritabanını paylaşıyor ve tüm süreç zaman alıyor. Bu nedenle, veritabanı güncellemesi ve ortam değişimi arasındaki zaman aralığında, çevrimiçi kullanıcılar eski kodla üretim ortamında kalırken yeni veritabanı ile iletişim kurmaya çalışır.
Bu, olayın temel nedeniydi ve 35 dakika içinde otomatik olarak çözülmesinin nedeniydi.
Veritabanı değişikliklerinin geriye dönük uyumluluğunu kontrol etmek için bir CI görevi VAR. Ancak, daha önce PR'yi birleştirmeden önce CI kontrolünü geçmesi gerekmiyordu. Bunun nedeni, genellikle geliştirme aşamasının birkaç sprint içinde kısa olması ve şema değişikliklerinin ilk ve ikinci kısmının genellikle aynı sürüm aşamasına dahil edilmesi gerektiğidir.
Bu sefer, özellik yayını ertelendi ve şema değişiklikleri iki dağıtım arasında yayıldı. Geliştirici, CI başarısızlığının beklenen bir durum olduğunu varsaydı ve incelemecilere PR'yi birleştirmelerini engellememesi gerektiğini bildirdi.
Kesinlikle bir iletişim açığı vardı ve sonuçta gerekli geriye dönük uyumluluk desteği sağlanmadan PR birleştirildi.