เมื่อเวิร์กโฟลว์ n8n เชื่อมต่อ API ไม่ได้ ต้องกู้คืนอย่างไร

รอบที่ล้มเหลวอาจแก้ข้อมูลไปแล้วบางส่วน

สมมติระบบรับคำขอ สร้างผู้ติดต่อใน CRM แล้วส่งข้อความยืนยัน หาก API ส่งข้อความล้มเหลวหลังสร้างผู้ติดต่อ ข้อมูลผู้ติดต่ออาจอยู่ในระบบแล้ว การเริ่มใหม่ทั้งหมดอาจสร้างคนเดิมหรือส่งข้อความซ้ำ โดยทั่วไป n8n ย้อนคืนการเขียนข้อมูลข้ามบริการอิสระไม่ได้

แยกสถานะการรันออกจากผลที่เกิดกับงานจริง สำหรับแต่ละเหตุการณ์ที่รับเข้า ให้ติดตามว่าการทำงานในระบบภายนอกส่วนใดเสร็จแล้วและส่วนใดยังไม่แน่ชัด กรณีหมดเวลาต้องระวังเป็นพิเศษ เพราะปลายทางอาจรับคำขอแล้วแต่คำตอบกลับสูญหาย

หาสาเหตุก่อนตัดสินใจลองใหม่

เก็บ endpoint ชื่อโหนด รหัสสถานะ หมายเลขอ้างอิงการรัน และข้อความผิดพลาดที่ปกปิดข้อมูลอ่อนไหวแล้ว อ่านข้อความตอบกลับของผู้ให้บริการควบคู่กับรหัส HTTP เพราะสถานะเดียวกันอาจเกิดได้หลายสาเหตุ การกดเชื่อมต่อใหม่แก้คำขอผิดรูปแบบไม่ได้

ตามเอกสาร n8n โหนด HTTP Request ถือคำตอบ 2xx ว่าสำเร็จตามปกติ ตัวเลือก Never Error เปลี่ยนพฤติกรรมนี้ หากใช้เพื่อตรวจคำตอบ ต้องเพิ่มทางแยกที่ตรวจสถานะและช่องข้อผิดพลาดของผู้ให้บริการก่อนทำขั้นตอนต่อไป

ที่มา: n8n: ตัวเลือกคำตอบของ HTTP Request

ให้การแจ้งเตือนทำงานได้แม้การเชื่อมต่อหลักเสีย

สร้างเวิร์กโฟลว์แยกที่เริ่มด้วย Error Trigger แล้วเลือกไว้ในการตั้งค่าของเวิร์กโฟลว์หลัก n8n ระบุว่า Error Trigger ทำงานเมื่อการรันอัตโนมัติล้มเหลว ไม่ทำงานกับการกดทดสอบเอง จึงต้องทดสอบการแจ้งเตือนด้วยการรันอัตโนมัติที่ควบคุมเงื่อนไขและใช้ข้อมูลทดสอบ

แจ้งชื่อเวิร์กโฟลว์ ขั้นตอนที่ล้มเหลว เวลาเกิดเหตุ และลิงก์การรันที่บันทึกไว้ถ้ามีให้ผู้รับผิดชอบ อย่าใส่ข้อมูลยืนยันตัวตนหรือข้อมูลลูกค้าในข้อความ และเลือกช่องทางแจ้งเตือนที่ไม่ใช้การเชื่อมต่อเดียวกับที่เสีย

ทางแยกจัดการข้อผิดพลาดอาจทำให้การรันดูเหมือนสำเร็จ จึงต้องติดตามคิวข้อยกเว้นและระยะเวลาที่งานค้างด้วย หากไม่มีเหตุการณ์เข้าเพราะตัวรับเหตุการณ์หยุดทำงาน การเตือนในขั้นตอนถัดไปจะไม่ช่วย ต้องมีการตรวจสุขภาพระบบหรือปริมาณงานที่คาดว่าจะเข้ามาแยกต่างหาก

ที่มา: n8n: การทำงานและตั้งค่า Error Trigger

ป้องกันผลซ้ำเมื่อได้รับเหตุการณ์เดิม

กำหนดรหัสคงที่ให้แต่ละการกระทำ เช่น รหัสเหตุการณ์ต้นทางรวมกับชื่องาน เก็บในบันทึกถาวรพร้อมสถานะรอ เสร็จ และยังไม่แน่ชัด บังคับความไม่ซ้ำแบบอะตอมมิก เพื่อไม่ให้สองรอบที่ทำงานพร้อมกันรับงานเดียวกันได้ ใช้กลไก idempotency ของ API ปลายทางหากรองรับ

บันทึกในระบบเราอย่างเดียวรับประกันการทำงานเพียงครั้งเดียวข้ามสองระบบไม่ได้ หากปลายทางเขียนสำเร็จแต่บันทึกฝั่งเราล้มเหลว รอบถัดไปยังต้องตรวจสอบให้ตรงกัน ค้นรายการหรือสถานะคำขอด้วยรหัสอ้างอิงเดิมก่อนเขียนอีกครั้ง หาก API ตรวจแบบนี้ไม่ได้ ให้คนจัดการรายการที่ยังไม่แน่ชัด

สำหรับปัญหาชั่วคราว ให้จำกัดจำนวนครั้งที่ลองใหม่ เพิ่มช่วงรอแต่ละครั้ง และสุ่มช่วงรอเล็กน้อยตามความเหมาะสม ระบุว่าลองได้กี่ครั้งและรายการที่ยังไม่สำเร็จจะไปที่ใด การเรียก API ซ้ำด้วยข้อมูลยืนยันตัวตนที่ถูกเพิกถอนเพิ่มเพียงปริมาณคำขอ ไม่ได้คืนสิทธิ์

ทยอยกู้งานค้างตามลำดับ

หยุดการเขียนที่มีปัญหาหากการล้มเหลวซ้ำอาจสร้างข้อมูลซ้ำ บันทึกเวลาเริ่มเหตุและเก็บข้อมูลที่รอในแหล่งถาวรที่อนุมัติ แก้ข้อมูลยืนยันตัวตนหรือปัญหาผู้ให้บริการ แล้วทดสอบการอ่านหรือรายการทดสอบที่ลบทิ้งได้ก่อนปล่อยงานจริง

ตรวจรายการที่ไม่แน่ชัดก่อน จากนั้นลองทำงานค้างชุดเล็ก ตรวจข้อมูลปลายทางและจำนวนข้อความ แล้วค่อยเพิ่มปริมาณภายในขีดจำกัดของผู้ให้บริการ เทียบเหตุการณ์ที่รับเข้ากับรายการที่เสร็จ รอ และปฏิเสธโดยตั้งใจ ปิดเหตุเมื่ออธิบายผลของทุกรายการได้แล้ว

ทดสอบความเสียหายก่อนเปิดใช้งาน

ในระบบทดสอบ ให้จำลองการเพิกถอนสิทธิ์ คำขอเกินขีดจำกัด บริการปลายทางล่ม และคำตอบสูญหายหลังเขียนสำเร็จ ส่งเหตุการณ์เดิมสองครั้งและให้ตัวประมวลผลสองตัวแย่งงานเดียวกัน ตรวจว่าแต่ละการกระทำเกิดครั้งเดียวหรือเข้าสถานะรอตรวจอย่างชัดเจน

เขียนคู่มือกู้คืนสั้น ๆ ระบุผู้รับผิดชอบ ผู้สำรอง ปุ่มหยุด และขั้นตอนทำงานค้างซ้ำ วัดอายุของงานค้างที่เก่าที่สุด เพราะคิวที่สะสมโดยไม่มีใครรู้ทำให้การติดตามลูกค้าเสียหายได้ แม้การรันส่วนใหญ่จะดูปกติ