ปุ่ม Inline ของ Telegram โหลดไม่หยุด? ตรวจสอบ answerCallbackQuery

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

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

• ปุ่ม callback สร้าง callback_query ไม่ใช่ข้อความธรรมดาที่ส่งเข้า message handler
• ใช้ id ของ query เป็น callback_query_id ไม่ใช่ ID ของข้อความ แชต หรือ update
• ข้อความแจ้งเตือนไม่ใช่พารามิเตอร์บังคับ จึงตอบโดยไม่แสดงข้อความได้
• สัญลักษณ์โหลดหายไปไม่ได้ยืนยันว่าการชำระเงิน การอนุมัติ หรืองานบริการลูกค้าเสร็จแล้ว

ทำไมปุ่มที่โหลดค้างจึงต้องใช้ answerCallbackQuery

เอกสาร Telegram Bot API อย่างเป็นทางการ แยกปุ่ม callback ออกจากปุ่ม URL โดย callback_data จะถูกส่งให้บอตผ่าน callback query ส่วนปุ่ม URL จะเปิดลิงก์ที่กำหนด ก่อนตรวจระบบ ให้ยืนยันก่อนว่าคุณสร้างปุ่มประเภทใด

การกดปุ่ม callback มีผลลัพธ์ที่ต้องแยกกันสามส่วน:

ผลลัพธ์	หลักฐานยืนยัน	สิ่งที่ยังยืนยันไม่ได้
รับทราบการส่ง webhook	HTTP response ที่สำเร็จจากตัวรับ	callback ได้รับคำตอบแล้ว
ตอบการกดปุ่มแล้ว	เรียก answerCallbackQuery สำหรับ query นั้น	งานธุรกิจสำเร็จแล้ว
งานธุรกิจเสร็จแล้ว	ผลลัพธ์ที่แอปพลิเคชันบันทึกสำเร็จ	การรับหรือตอบการกดปุ่มอย่างเดียวไม่เพียงพอ

Telegram ระบุว่า answerCallbackQuery แสดง notification หรือ alert ได้ และคืนค่า True เมื่อสำเร็จ พารามิเตอร์บังคับคือ callback_query_id ส่วน text เป็นตัวเลือก การตอบรับ webhook ตามปกติใช้แทนกันไม่ได้

หากกำลังตัดสินใจว่าจะใส่เมธอด Bot API ใน response body ของ webhook หรือเรียกแยก ให้อ่าน response body ของ webhook เทียบกับคำขอ API แยก ประเด็นนั้นเกี่ยวกับวิธีเรียก API ส่วนบทความนี้เน้นการตอบการโต้ตอบของปุ่มที่ขาดหายไป

หาจุดที่ขัดข้อง

ไม่มี callback มาถึง handler

ตรวจชนิดของ update ที่ได้รับ ไม่ใช่ค้นเฉพาะ log ของข้อความ ตรวจว่า dispatcher รองรับ callback_query และตัวกรอง allowed_updates ที่กำหนดไว้อย่างชัดเจนมีชนิดนี้อยู่ด้วย Telegram ระบุว่าเมื่อไม่ส่ง allowed_updates จะใช้ค่าก่อนหน้า ดังนั้นการละพารามิเตอร์นี้ในการตั้งค่าครั้งถัดไปไม่ได้ล้างตัวกรอง

หาก update ทั้งรายการไม่มาถึง ให้ใช้คู่มือวิเคราะห์การส่งด้วย getWebhookInfo ปัญหาการส่งกับ handler ที่ละเลย callback ต้องแก้คนละจุด

callback มาถึง แต่ปุ่มยังโหลดอยู่

เทียบฟิลด์เหล่านี้กับ update ที่ได้รับจริง:

ฟิลด์ขาเข้า	การใช้งาน
callback_query.id	ส่งเป็น callback_query_id ให้ answerCallbackQuery
callback_query.data	ใช้เป็นข้อมูลนำเข้าของแอปเมื่อมีฟิลด์นี้
callback_query.message	บริบทข้อความเมื่อมี อย่ากำหนดว่าทุก callback ต้องมี
callback_query.inline_message_id	ระบุข้อความที่ส่งผ่าน inline mode เมื่อมี

Telegram ให้บริบทต่างกันระหว่างข้อความบอตทั่วไปกับข้อความผ่าน inline mode หากโค้ดเข้าถึง callback_query.message.chat ทุกครั้ง อาจเกิดข้อผิดพลาดก่อนถึงการเรียกตอบ callback

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

หยุดโหลดแล้ว แต่งานทำงานผิด

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

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

ทดสอบการโต้ตอบ ไม่ใช่แค่ webhook

ก่อนเปิดใช้งาน ให้ตรวจกรณีเหล่านี้:

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

นี่คือรายการทดสอบที่แนะนำ ไม่ใช่ผลทดสอบที่ดำเนินการแล้วหรือการรับประกันเวลาในการตอบจาก Telegram

ขอบเขตของ UnifyPort

สำหรับ inline keyboard ของบอตและการตอบ callback ให้ใช้ Telegram Bot API อย่างเป็นทางการต่อไป ส่วน unofficial interface ของ UnifyPort ใช้กับบัญชีรับส่งข้อความที่เชื่อมต่อ และมีข้อกำหนดอีเวนต์มาตรฐานคนละชุด รายการอีเวนต์ webhook สาธารณะ มี message.received แต่ไม่ได้ระบุอีเวนต์ callback_query หรือการทำงาน answerCallbackQuery อย่าเปลี่ยนชื่ออีเวนต์ข้อความให้เป็น callback หรือถือว่า unified webhook จะตอบปุ่มให้บอต

หากต้องรับข้อความระดับบัญชีจากช่องทางอย่าง LINE ด้วย ให้แยกตัวรับนั้นออกจาก handler การโต้ตอบของบอต เอกสารการส่ง webhook ของ UnifyPort ระบุว่าจะทิ้ง response body การส่ง JSON ของเมธอด Bot API กลับไปที่จุดนี้จึงไม่ทำให้มีการตอบ callback

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

HTTP 200 ทำให้ปุ่ม Telegram หยุดโหลดหรือไม่?

ไม่ใช่ด้วยสถานะนี้เพียงอย่างเดียว HTTP ใช้รับทราบการส่ง update ส่วน callback ต้องใช้ answerCallbackQuery

ต้องส่งข้อความพร้อม answerCallbackQuery หรือไม่?

ไม่จำเป็น text เป็นพารามิเตอร์ตัวเลือก จึงตอบได้โดยไม่แสดงข้อความแจ้งเตือน

ใช้ ID ของข้อความเป็น callback_query_id ได้หรือไม่?

ไม่ได้ ต้องใช้ id ของ CallbackQuery ที่ได้รับ

unified message webhook ใช้แทน handler นี้ได้หรือไม่?

ไม่ได้ตามข้อกำหนดที่ UnifyPort เผยแพร่ ควรเก็บการจัดการ callback ไว้ในระบบบอต Telegram อย่างเป็นทางการ

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

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

ตรวจแหล่งข้อมูลทางการเมื่อ 2026-09-22: Telegram Bot API — CallbackQuery, answerCallbackQuery, InlineKeyboardButton และ allowed_updates