การตรวจสอบหลังเกิดเหตุ: เกิดข้อผิดพลาด 500 อย่างไม่คาดคิดในระหว่างการลงชื่อเข้าใช้ของผู้ใช้
รายงานเหตุการณ์สำหรับข้อผิดพลาด 500 อย่างไม่คาดคิดที่ได้รับจากบริการยืนยันตัวตนเมื่อวันที่ 18 กรกฎาคม 2024
รายงานเหตุการณ์สำหรับข้อผิดพลาด 500 อย่างไม่คาดคิดที่ได้รับจากบริการยืนยันตัวตนเมื่อวันที่ 18 กรกฎาคม 2024
เมื่อวันที่ 18 กรกฎาคม 2024 Logto Cloud เกิดการหยุดให้บริการโดยแสดงข้อผิดพลาด 500 Internal server error จากบริการยืนยันตัวตน
ระหว่างการปรับใช้ Cloud ล่าสุด การเปลี่ยนแปลงที่มีผลกระทบในโครงสร้างฐานข้อมูลทำให้ API ประสบการณ์การลงชื่อเข้าใช้ล้มเหลวระหว่างการเปลี่ยนผ่านระหว่างสภาพแวดล้อม staging และ production
ขณะนี้เรากำลังพัฒนาฟีเจอร์ใหม่ชื่อว่า "Bring your UI" ซึ่งจะอนุญาตให้ผู้ใช้ปรับแต่งประสบการณ์การลงชื่อเข้าใช้ของ Logto ด้วยเว็บเพจของตนเอง ฟีเจอร์นี้ต้องการคอลัมน์ใหม่ในตาราง sign-in-exp เพื่อเก็บการกำหนดค่า UI แบบกำหนดเอง
เนื่องจากมีการเปลี่ยนแปลงข้อกำหนดระหว่างการพัฒนา การปล่อยฟีเจอร์นี้จึงล่าช้า แต่ส่วนแรกของการเปลี่ยนแปลงโครงสร้างได้ถูกปรับใช้ไปยัง production เมื่อหลายสัปดาห์ก่อนแล้ว แม้ว่าจะยังไม่มีการใช้งานก็ตาม การอัปเดตคอลัมน์ในฐานข้อมูลถูกแนะนำใน PR นี้
น่าเสียดายที่การเปลี่ยนแปลงนี้ไม่รองรับย้อยกลับ ทำให้คำขอ API จากโค้ดเก่าล้มเหลวในการติดต่อสื่อสารกับฐานข้อมูลใหม่
เมื่อปรับใช้เวอร์ชันใหม่ของ Logto Cloud เราจะปรับใช้ไปยังสภาพแวดล้อม staging ก่อนแล้วจึงสลับสภาพแวดล้อม staging และ production ขั้นตอนเป็นดังนี้:
อย่างไรก็ตาม ทั้งสองสภาพแวดล้อมใช้ฐานข้อมูลเดียวกัน และกระบวนการทั้งหมดใช้เวลา ดังนั้นในช่วงเวลาระหว่างการอัปเดตฐานข้อมูลและการสลับสภาพแวดล้อม ผู้ใช้ออนไลน์ยังคงอยู่ในสภาพแวดล้อม production ด้วยโค้ดเก่าแต่พยายามติดต่อสื่อสารกับฐานข้อมูลใหม่
นี่เป็นสาเหตุหลักของเหตุการณ์และเหตุผลที่มันได้รับการแก้ไขโดยอัตโนมัติใน 35 นาที
เรามีงาน CI เพื่อตรวจสอบความเข้ากันได้ย้อนหลังของการเปลี่ยนแปลงฐานข้อมูล แต่อดีตไม่จำเป็นต้องผ่านการตรวจสอบ CI ก่อนที่จะรวม PR นี้ เนื่องจากเวลาส่วนใหญ่ในระยะการพัฒนามักจะสั้นในไม่กี่ช่วงและส่วนแรกและส่วนที่สองของการเปลี่ยนแปลงโครงสร้างมักจะรวมอยู่ในระยะการปล่อยเดียวกัน
ครั้งนี้ การปล่อยฟีเจอร์ล่าช้า การเปลี่ยนแปลงโครงสร้างกระจายไปอยู่ในสองการปล่อย ดีเวลลอปเปอร์ถือว่าความล้มเหลวใน CI เป็นสิ่งที่ควรคาดหวังและแจ้งผู้ตรวจสอบว่าไม่ควรบล็อค PR นี้
ช่องว่างในการสื่อสารเป็นสิ่งที่แน่นอนเช่นกัน และสุดท้าย PR ก็ถูกผสานโดยไม่ต้องมีการรองรับความเข้ากันได้ย้อนหลังอย่างจำเป็น