LINE X-Line-Retry-Key: ส่งคำขอซ้ำหลัง timeout โดยไม่ส่งข้อความซ้ำ
สำหรับการส่งผ่าน LINE Messaging API ที่รองรับ ให้ใส่ X-Line-Retry-Key ตั้งแต่คำขอแรก แล้วใช้ key ผู้รับ และเนื้อหาเดิมเมื่อต้องลองใหม่หลัง timeout หรือข้อผิดพลาดฝั่งเซิร์ฟเวอร์ที่ลองใหม่ได้ สร้าง UUID แบบเลขฐานสิบหกสำหรับคำขอเชิงตรรกะแต่ละรายการ หากได้รับ 409 ที่ระบุว่า key นี้ถูกรับแล้ว ให้หยุด ไม่ใช่เปลี่ยน key แล้วส่งอีก วิธีนี้ป้องกันการรับคำขอซ้ำภายในช่วงเวลาที่กำหนด แต่ไม่รับประกันว่าผู้ใช้จะได้รับข้อความ
ประเด็นสำคัญ
- Push, multicast, narrowcast และ broadcast รองรับ retry key ไม่ใช่ทุก LINE API
- บันทึก key และคำขอต้นฉบับลงที่เก็บถาวรก่อนส่ง ไม่ใช่หลังเกิดข้อผิดพลาด
- LINE ระบุว่า key มีอายุ 24 ชั่วโมงนับจากคำขอแรก
- แยกการรับคำขอ การส่งถึงผู้รับ และการตอบรับ webhook ขาเข้าออกจากกัน
X-Line-Retry-Key ป้องกันอะไร
Timeout หมายความว่าแอปไม่ได้รับคำตอบ แต่ LINE อาจรับคำขอส่งข้อความไปแล้ว การสร้าง UUID ใหม่ทุกครั้งทำให้ผลลัพธ์ที่ยังไม่แน่ชัดกลายเป็นคำขออิสระอีกหนึ่งรายการ
คู่มือการลองคำขอใหม่ของ LINE อธิบายว่า เมื่อคำขอที่มี key ถูกรับแล้ว ความพยายามครั้งต่อไปด้วย key เดิมจะถูกปฏิเสธว่าเป็นคำขอซ้ำ ต้องใส่ key ตั้งแต่ครั้งแรก การเพิ่ม key หลังคำขอที่ไม่มี key เกิด timeout ไม่สามารถป้องกันคำขอเดิมย้อนหลังได้
| วิธีส่ง | การรองรับ retry key ตามเอกสาร LINE |
|---|---|
| Push | รองรับ |
| Multicast | รองรับ |
| Narrowcast | รองรับ |
| Broadcast | รองรับ |
| API อื่น รวมถึง reply messages | ไม่อยู่ในรายการนี้ อย่าแนบ header ให้ทุก API |
LINE ระบุว่าการใส่ header นี้ใน API ที่ไม่รองรับจะได้รับ 400 และนี่ไม่ใช่กระบวนการ notification token ของ LINE MINI App หากปัญหาอยู่ที่ระบบนั้น ให้ใช้คู่มือแก้ข้อผิดพลาด Service Message API แทนการใช้กติกาในบทความนี้
บันทึกข้อมูลก่อนเรียกผ่านเครือข่าย
ส่วนนี้เป็นข้อเสนอแนะด้านการออกแบบแอป ไม่ใช่ฟิลด์เพิ่มเติมของ LINE API
สร้างระเบียนส่งข้อความแบบถาวรที่เก็บรหัสงานทางธุรกิจ ตัวตนของ channel วิธีส่ง request body ทั้งชุด retry UUID เวลาเริ่มพยายามครั้งแรก เวลาสิ้นสุดการลองใหม่ และสถานะงาน ปกป้องข้อมูลผู้รับและข้อความตามนโยบายเก็บข้อมูล ส่วน access token ควรอ่านจากการตั้งค่าที่ปลอดภัย ไม่ใส่ในระเบียนงานหรือ log ทั่วไป
บันทึกให้สำเร็จก่อนส่ง ทุกครั้งที่ลองใหม่ให้โหลด key และคำขอที่บันทึกไว้ อย่าสร้างข้อความใหม่จากข้อมูลคำสั่งซื้อหรือลูกค้าที่อาจเปลี่ยนไป LINE ระบุชัดว่าห้ามเปลี่ยนเนื้อหาหรือผู้รับเมื่อใช้ key เดิม
กำหนดรหัสงานทางธุรกิจที่ไม่ซ้ำ และใช้การจองงานหรือ lock สำหรับ worker มิฉะนั้น worker สองตัวอาจสร้าง UUID คนละค่าให้กับการทำงานเดียวกัน และทั้งสองคำขอก็ถูกรับได้ Retry key ตรวจจับคำขอที่ใช้ key เดียวกัน ไม่ได้รู้ว่างานที่สร้างแยกกันมีความหมายทางธุรกิจเหมือนกัน
หากหลายเครื่องมือใช้ Official Account เดียวกัน ต้องกำหนดเจ้าของการส่งแต่ละประเภทก่อน รายการตรวจสอบการใช้หลายเครื่องมือ อธิบายขอบเขต channel ที่ใช้ร่วมกัน ส่วน outbox ภายในแอปช่วยกำหนดเจ้าของงานส่งแต่ละรายการ
ตัดสินใจจากผลลัพธ์จริง
ทำตามแนวทางลองใหม่ตาม status code ของ LINE อย่าถือว่าทุกคำตอบที่ไม่สำเร็จอนุญาตให้ส่งซ้ำ
| ผลที่ได้รับ | การทำงานของ worker ที่แนะนำ |
|---|---|
2xx | บันทึกว่ารับคำขอแล้วและหยุดลองใหม่ |
| Timeout หรือปัญหาเซิร์ฟเวอร์ที่ลองใหม่ได้ | นัดลองใหม่ภายในงบที่กำหนด โดยใช้ key และคำขอเดิม |
409 ที่ระบุว่า key ถูกรับแล้ว | บันทึกการรับก่อนหน้า เก็บ x-line-accepted-request-id แล้วหยุด |
4xx อื่น | หยุดการลองคำขอเดิมซ้ำและตรวจสอบคำขอหรือข้อจำกัด |
| หมดช่วงเวลาโดยยังไม่ทราบว่าถูกรับหรือไม่ | ส่งไปตรวจสอบหรือให้ผู้ดูแลตัดสินใจ ไม่เปลี่ยน key อัตโนมัติ |
เมื่อปฏิเสธคำขอซ้ำ LINE ส่ง x-line-accepted-request-id เพื่อระบุคำขอที่สำเร็จ ให้แยกจาก x-line-request-id ซึ่งระบุการเรียกแต่ละครั้ง เก็บสถานะ เวลา และรายละเอียดวิเคราะห์ที่ปิดบังข้อมูลสำคัญแล้ว อย่าใช้ข้อความ error เพียงอย่างเดียวในการเลือกทางทำงาน
LINE แนะนำ exponential backoff และระบุว่าการลองใหม่ถูกนับใน rate limit ของ API ด้วย Scheduler ควรมีงบจำนวนครั้งของตนเอง และไม่จัดงานเลยอายุ key 24 ชั่วโมง ช่วงเวลานับจากคำขอแรก ไม่ได้เริ่มใหม่ทุกครั้งที่ลองซ้ำ แอปอาจกำหนดเส้นตายที่สั้นกว่านี้เพื่อความปลอดภัย
เมื่อ key หมดอายุ ผลที่ไม่ทราบก็ยังไม่ทราบ Key ใหม่คือการตัดสินใจส่งครั้งใหม่ และอาจซ้ำกับข้อความที่ถูกรับไปแล้ว จึงควรตรวจสอบหรือขออนุมัติอย่างชัดเจน ไม่ใช้การเปลี่ยน key เป็นขั้นตอนกู้คืนปกติ
รับคำขอแล้วไม่ได้แปลว่าส่งถึงแล้ว
LINE เตือนว่า retry key ไม่รับประกันการส่งถึงผู้รับ เช่น ผู้ใช้ที่บล็อก Official Account อาจไม่ได้รับข้อความแม้คำขอจะถูกรับ การส่งคำขอเดิมด้วย key เดิมซ้ำหลังรับแล้วไม่ใช่วิธีแก้ปัญหาการส่งถึง
สถานะในแอปควรแยก “LINE รับคำขอแล้ว” ออกจาก “ลูกค้าอ่านแล้ว” เช่นเดียวกับการที่ webhook receiver ของคุณตอบสำเร็จ นั่นยืนยันการรับเหตุการณ์ขาเข้า ไม่ได้ยืนยันว่าข้อความตอบกลับถูกส่งแล้ว
สัญญาของ UnifyPort เป็นอีกชุดหนึ่ง
อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort เชื่อมต่อบัญชีรับส่งข้อความและส่งเหตุการณ์มาตรฐาน เช่น message.received ไม่ใช่เครื่องมือส่งอีกตัวภายใน channel ของ LINE Official Account เดียวกัน และเอกสารส่งข้อความสาธารณะไม่ได้ระบุการรองรับ X-Line-Retry-Key
ก่อนออกแบบการลองส่งใหม่ผ่าน UnifyPort ให้อ่านข้อกำหนดการส่งข้อความตัวอักษร อย่านำอายุ key 24 ชั่วโมงหรือคำตอบเมื่อรับซ้ำของ LINE มาใช้โดยตรง รหัสติดตามคำขอไม่ได้รับประกัน idempotency โดยอัตโนมัติ
สำหรับขาเข้า ให้ตั้ง signing_secret และตรวจ X-Device-Signature ด้วย HMAC-SHA256 ของ X-Device-Timestamp ตามด้วยจุดและ request body ดิบ ใช้เอกสารการส่ง webhook เป็นหลักสำหรับการตอบรับและการลองใหม่ การกำจัดเหตุการณ์ขาเข้าซ้ำกับการป้องกันส่งข้อความขาออกซ้ำเป็นคนละปัญหา การทำอย่างหนึ่งไม่ได้ทำให้อีกอย่างสำเร็จด้วย
หากต้องใช้ความสามารถส่งข้อความของ Official Account ให้ใช้ Messaging API ทางการ การเปลี่ยนไปเชื่อมต่อบัญชีทั่วไปไม่ได้แก้ผลลัพธ์ที่ไม่แน่ชัดของคำขอซึ่งส่งผ่าน API ทางการไปแล้ว
คำถามที่พบบ่อย
สร้าง key หลัง timeout ครั้งแรกได้ไหม?
ไม่สามารถใช้ป้องกันคำขอเดิมได้ ต้องใส่ key ตั้งแต่ความพยายามแรกของ API ที่รองรับ
ได้ 409 แล้วควรเปลี่ยน UUID หรือไม่?
ไม่ควร หากหมายถึง key เดิมถูกรับแล้ว ให้เก็บรหัสคำขอที่สำเร็จและจบการลองใหม่ของงานนั้น
เปลี่ยนผู้รับแต่ใช้ key เดิมได้ไหม?
ไม่ได้ LINE กำหนดให้เนื้อหาและผู้รับเหมือนเดิม การเปลี่ยนงานทางธุรกิจต้องเป็นการตัดสินใจแยก ไม่ใช่แก้คำขอที่กำลังลองใหม่
ใช้กับทุก LINE message API ได้ไหม?
ไม่ได้ ใช้เฉพาะวิธีที่ระบุว่ารองรับ อย่านำไปใช้กับ MINI App service messages หรือการส่งผ่าน UnifyPort
ขั้นตอนต่อไปและแหล่งอ้างอิง
ตรวจ worker ขาออกหนึ่งตัวว่า หลัง process หยุดทำงานกะทันหัน สามารถกู้คืนkey เดิมและคำขอเดิมได้หรือไม่ ทดสอบด้วย mock ในเครื่องก่อน แล้วจึงทดสอบการส่งจริงแบบควบคุม สำหรับการเชื่อมต่อบัญชีรับส่งข้อความ ให้อ่านเอกสารส่งข้อความของ UnifyPort
ตรวจสอบแหล่งข้อมูลทางการเมื่อ 2026-09-28:
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน