Telegram getWebhookInfo: ตรวจสอบอัปเดตค้างส่งและข้อผิดพลาด webhook

เมื่ออัปเดตจาก Telegram webhook ดูเหมือนค้าง ให้ตรวจ getWebhookInfo ก่อนเปลี่ยนการตั้งค่า ค่า pending_update_count คือจำนวนอัปเดตที่รอส่ง ไม่ใช่จำนวนงานที่แอปยังทำไม่เสร็จ ต้องอ่านร่วมกับ last_error_date, last_error_message และบันทึกของระบบรับข้อมูล ยอดค้างเป็นศูนย์ไม่ได้ยืนยันว่ากระบวนการธุรกิจเสร็จแล้ว และการมีข้อความผิดพลาดค้างอยู่ก็ไม่ได้แปลว่าปลายทางยังล้มเหลวในขณะนี้

ประเด็นสำคัญ

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

getWebhookInfo บอกอะไรได้จริง

เอกสาร Telegram Bot API ระบุว่า getWebhookInfo ไม่ต้องรับพารามิเตอร์ และคืนออบเจ็กต์ WebhookInfo เรียกผ่านไคลเอนต์ Bot API ที่มีอยู่ในสภาพแวดล้อมที่เชื่อถือได้ อย่าใส่ bot token หรือ webhook URL ที่มีข้อมูลอ่อนไหวไว้ในบันทึกหรือภาพหน้าจอที่แชร์กัน

ฟิลด์	ความหมายตามเอกสาร	ใช้ตรวจสอบอะไร
url	URL ของ webhook; ว่างเมื่อยังไม่ได้ตั้งค่า	ปลายทางเป็นของสภาพแวดล้อมที่ตั้งใจหรือไม่
pending_update_count	จำนวนอัปเดตที่รอส่ง	เปรียบเทียบว่ายอดค้างเพิ่มหรือลด
last_error_date	ฟิลด์ไม่บังคับ: เวลา Unix ของข้อผิดพลาดการส่ง webhook ล่าสุด	ข้อผิดพลาดเกิดก่อนการแก้ไขหรือไม่
last_error_message	ฟิลด์ไม่บังคับ: คำอธิบายข้อผิดพลาดที่อ่านได้	เลือกจุดตรวจต่อ ไม่ใช้เป็นรหัสข้อผิดพลาดแบบคงที่
ip_address	ฟิลด์ไม่บังคับ: IP ของ webhook ที่กำลังใช้งาน	เทียบกับปลายทางสาธารณะที่ต้องการ
last_synchronization_error_date	ฟิลด์ไม่บังคับ: เวลาข้อผิดพลาดล่าสุดขณะซิงก์อัปเดตกับศูนย์ข้อมูล Telegram	แยกจากปัญหาเชื่อมต่อระบบรับข้อมูล

การมี URL ไม่ได้พิสูจน์ว่าเข้าถึงได้ และการไม่มีฟิลด์ข้อผิดพลาดก็ไม่ได้ยืนยันว่า CRM หรือ worker ทำงานเสร็จแล้ว

ถ้า url ว่าง ให้ยืนยันก่อนว่า bot นี้ควรใช้ webhook จริงหรือไม่ หากต้องเปลี่ยนวิธีรับข้อมูล ให้อ่าน ขั้นตอนสลับ getUpdates กับ setWebhook แทน บทความนี้ตรวจเส้นทางส่งข้อมูลโดยคง webhook เดิมไว้

อ่านยอดค้างร่วมกับเวลาของข้อผิดพลาด

บันทึกสถานะเริ่มต้น ส่งข้อความทดสอบที่ควบคุมได้และ bot ควรรับได้ แล้วตรวจสถานะอีกครั้ง จดเวลาที่ตรวจในบันทึกปฏิบัติงานของคุณเอง อย่าถือว่าเวลานั้นเป็นฟิลด์ที่ Telegram ส่งกลับ

สิ่งที่พบ	อาจหมายถึง	ตรวจต่อที่ใด
ยอดค้างเพิ่มและเวลาข้อผิดพลาดการส่งเปลี่ยนเป็นเวลาล่าสุด	ยังมีการส่งล้มเหลวระหว่างที่ตรวจ	จุดรับสาธารณะ, TLS, routing และบันทึก HTTP response
ยอดค้างลดแต่เวลาข้อผิดพลาดยังเป็นค่าเก่า	การส่งอาจกำลังกลับมาทำงาน	ยืนยันว่าข้อความทดสอบถูกบันทึกและประมวลผล
ยอดค้างเป็นศูนย์แต่ไม่มีผลทางธุรกิจ	ตัวเลขอย่างเดียวระบุจุดเสียไม่ได้	storage, คิวภายใน, worker และกฎ routing
ยังมียอดค้างแต่ไม่มีข้อผิดพลาดใหม่	สถานะครั้งเดียวยังสรุปไม่ได้	ตรวจซ้ำและเทียบกับทราฟฟิกขาเข้า
เวลาข้อผิดพลาดการซิงก์เปลี่ยนเป็นเวลาล่าสุด	ข้อผิดพลาดเกี่ยวกับการซิงก์อัปเดตของ Telegram	เก็บหลักฐาน อย่าสรุปว่าเปลี่ยนใบรับรองแล้วจะหาย

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

ไล่ตรวจตามเส้นทางคำขอ

ใช้คำอธิบายข้อผิดพลาดล่าสุดจำกัดขอบเขต แล้วตรวจยืนยันด้วยข้อมูลของระบบคุณ:

1. ปลายทางสาธารณะ: เทียบ host และ path กับระบบ production ตรวจ DNS และ routing ของจุดรับ และเทียบ ip_address หากมี
2. TLS: ตรวจความถูกต้องของใบรับรอง ชื่อ host ที่ครอบคลุม และ certificate chain ที่ส่งจริง คู่มือ webhook ของ Telegram มีคำแนะนำด้านใบรับรอง อย่าลดความเข้มงวดของการตรวจสอบเพื่อซ่อนการตั้งค่าที่ผิด
3. การตอบ HTTP: ดูสถานะที่จุดรับสาธารณะตอบจริง ไม่ใช่เฉพาะ log ของแอป เพราะ proxy อาจตอบก่อน handler ทำงาน การเปิดหน้าเว็บด้วยเบราว์เซอร์ได้ก็ไม่ได้ยืนยันว่าเส้นทาง POST ของ webhook ใช้งานได้
4. การบันทึกถาวร: ตรวจว่าอัปเดตเข้าสู่ storage ที่คงทนแล้ว แนวทางที่แนะนำคือยืนยันแหล่งที่มาของคำขอ บันทึกลงกล่องรับหรือคิวถาวรให้สำเร็จ แล้วจึงตอบรับ งานภายนอกที่ใช้เวลานานควรทำภายหลัง
5. การประมวลผลธุรกิจ: ติดตามอัปเดตที่บันทึกไว้ผ่าน worker และออกแบบให้ประมวลผลซ้ำได้โดยไม่สร้างผลข้างเคียงซ้ำ

Telegram ระบุว่าจะส่ง webhook ซ้ำเมื่อคำขอไม่สำเร็จและได้รับสถานะที่ไม่ใช่ 2XY ก่อนหยุดหลังลองจำนวนครั้งที่เหมาะสม นี่ไม่ใช่ตารางเวลาลองใหม่แบบคงที่ที่เปิดเผยไว้ อย่ารับประกันเวลาฟื้นตัวโดยอาศัยช่วงเวลาที่คาดเดา

ยืนยันการฟื้นตัวโดยไม่ลบยอดค้าง

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

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

ช่วงเวลาที่อธิบายไม่ได้ยังต้องตรวจสอบย้อนหลัง การตอบรับ HTTP หมายถึงความสำเร็จตรงขอบเขตการส่งนั้น ไม่ใช่ความสำเร็จของงานธุรกิจทั้งหมด

UnifyPort เกี่ยวข้องอย่างไร และไม่ครอบคลุมอะไร

getWebhookInfo ใช้ตรวจ Telegram Bot API webhook ไม่ได้ตรวจระบบรับข้อมูลของ UnifyPort และไม่สามารถใช้ตัวตนอื่นกู้คืนอัปเดตที่ค้างของ bot ได้ หากยังเลือกตัวตนสำหรับรับข้อความ ให้อ่าน เปรียบเทียบ Telegram Bot API webhook กับ unified inbound webhook

อินเทอร์เฟซแบบไม่เป็นทางการของ UnifyPort ใช้สัญญาอีเวนต์แยกต่างหาก เช่น message.received เอกสารการส่ง webhook อธิบาย X-Device-Event-Id การตอบรับ และการลองใหม่ เมื่อกำหนด signing_secret ให้ตรวจ X-Device-Signature ด้วย HMAC-SHA256 บนข้อมูลที่ต่อกันจาก X-Device-Timestamp จุดหนึ่งตัว และ raw request body

แม้ทีมจะรวม LINE กับ Telegram ไว้ในคิวงานเดียวกัน ก็ควรแยกการติดตามเส้นทางนี้ออกจากสถานะ Bot API UnifyPort ไม่มี REST API สำหรับอ่านประวัติข้อความ และไม่รับประกันการส่ง payload ที่พลาดไปย้อนหลัง ระบบรับข้อมูลยังต้องรับผิดชอบการบันทึกถาวร หากผลิตภัณฑ์ต้องใช้ตัวตน bot ให้ใช้ Bot API ทางการต่อไป

คำถามที่พบบ่อย

pending_update_count คือจำนวนข้อความที่ยังไม่อ่านหรือไม่?

ไม่ใช่ เป็นจำนวนอัปเดตที่รอส่ง ไม่ใช่สถานะยังไม่อ่านในแชตหรือจำนวนงานค้างในแอป

ถ้ายังมี last_error_message แปลว่า webhook ยังเสียอยู่หรือไม่?

ไม่เสมอไป ฟิลด์นี้อธิบายข้อผิดพลาดการส่งล่าสุด ต้องเทียบเวลา ผลตรวจครั้งต่อมา และการทดสอบแบบครบเส้นทาง

ยอดค้างเป็นศูนย์แล้วปิดการตรวจสอบได้เลยหรือไม่?

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

ขั้นตอนถัดไปและแหล่งข้อมูล

สำหรับ bot ที่มีอยู่ ให้ตรวจ getWebhookInfo และติดตามอัปเดตทดสอบก่อนเปลี่ยนการตั้งค่า สำหรับการรับอีเวนต์จากบัญชีรับส่งข้อความที่เชื่อมต่อแล้ว เริ่มที่ สัญญาการส่งของ UnifyPort

ตรวจเอกสารทางการเมื่อ 2026-09-18:

• Telegram Bot API: WebhookInfo, setWebhook และ Getting updates
• คู่มือตรวจสอบ Telegram webhook