กลุ่ม Telegram เปลี่ยนเป็นซูเปอร์กรุ๊ป: อัปเดต Chat ID อย่างปลอดภัย

เมื่อกลุ่ม Telegram ย้ายเป็นซูเปอร์กรุ๊ป บอตต้องใช้รหัสแชตใหม่สำหรับการส่งครั้งถัดไป Bot API อาจส่ง migrate_to_chat_id หรือ migrate_from_chat_id มากับข้อความบริการ และอาจคืน parameters.migrate_to_chat_id ในผลตอบกลับของคำขอ API ที่ไม่สำเร็จ ให้บันทึกความสัมพันธ์ระหว่างรหัสเก่ากับรหัสใหม่อย่างชัดเจน แล้วเปลี่ยนปลายทางสำหรับงานใหม่ โดยคงรหัสแชตเดิมไว้ในข้อความที่เก็บเป็นประวัติ

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

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

migrate_to_chat_id และ migrate_from_chat_id หมายถึงอะไร

เอกสาร Bot API ทางการของ Telegram กำหนดสองฟิลด์นี้เป็นฟิลด์ทางเลือกของ Message และกำหนดฟิลด์ปลายทางการย้ายใน ResponseParameters ด้วย

หลักฐาน	แชตเก่า	แชตใหม่
ข้อความมี migrate_to_chat_id	chat.id ของข้อความนั้น	message.migrate_to_chat_id
ข้อความมี migrate_from_chat_id	message.migrate_from_chat_id	chat.id ของข้อความนั้น
ผลตอบกลับที่ล้มเหลวมี parameters.migrate_to_chat_id	รหัสแชตตัวเลขที่ใช้ในคำขอเดิม	parameters.migrate_to_chat_id

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

Telegram ระบุว่ารหัสเหล่านี้อาจมีบิตนัยสำคัญเกิน 32 บิต แต่ไม่เกิน 52 บิต จึงเก็บด้วยจำนวนเต็มแบบมีเครื่องหมาย 64 บิตหรือเลขทศนิยมแบบ double-precision ได้ ตรวจสอบว่าไม่มีการแปลงเป็น 32 บิตระหว่างทาง การใช้สตริงเลขฐานสิบเป็นคีย์ภายในแอปก็เป็นทางเลือกในการออกแบบ แต่ต้องเก็บเครื่องหมายและค่าครบถ้วน

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

ใช้ความสัมพันธ์แบบ alias แทนการเขียนประวัติใหม่

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

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

ลำดับที่แนะนำ:

1. ตรวจสอบแหล่งที่มาและเก็บอัปเดตอย่างถาวร หากเป็นข้อผิดพลาด API ให้เก็บผลตอบกลับจริงและคำขอเดิม
2. อ่านรหัสเก่าและใหม่ตามหลักฐานในตาราง
3. หากระบบจัดเก็บรองรับ ให้บันทึกการจับคู่และเปลี่ยนปลายทางปัจจุบันในธุรกรรมเดียวกัน
4. หลักฐานซ้ำของคู่เดิมไม่ควรสร้างงานเพิ่ม หากพบการจับคู่ขัดแย้งหรือวนเป็นวง ให้แยกไว้ตรวจสอบแทนการเขียนทับเงียบ ๆ
5. คงประวัติเดิมไว้ และให้คิวค้นหาปลายทางปัจจุบันก่อนส่งจริง

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

กู้การส่งในคิวโดยไม่ส่งซ้ำแบบไร้เงื่อนไข

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

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

หากต้องติดตามผลการส่ง อ่านการตอบใน webhook เทียบกับคำขอ sendMessage แยกต่างหาก การตอบรับข้อมูลขาเข้าสำเร็จไม่ใช่หลักฐานว่างานขาออกเสร็จแล้ว

ต่อไปนี้เป็นแผนทดสอบที่แนะนำ ไม่ใช่ผลการทดสอบที่รายงาน:

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

ขอบเขตของ UnifyPort

อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort ใช้ message.received พร้อม provider, account_id และ data.conversation.id ให้เก็บรหัสเหล่านี้ใน namespace ของตนเอง อย่าคิดว่านำ Bot API chat ID มาแทนได้โดยตรง หลักเดียวกันนี้สำคัญเมื่อออกแบบตัวรับร่วมกับ LINE: สคีมาร่วมไม่ได้ทำให้รหัสของแต่ละระบบใช้แทนกันได้

เอกสารอีเวนต์สาธารณะไม่ได้ระบุ migrate_to_chat_id, migrate_from_chat_id หรือรับประกันการจับคู่รหัสก่อนและหลังย้าย อย่าตีความ group.updated หรือ conversation.updated ว่าให้หลักประกันนั้น สำหรับบัญชีรับส่งข้อความ Telegram ที่เชื่อมต่อแล้ว ให้ตรวจสัญญา API รายการบทสนทนา และใช้ conversation_id ที่คืนมาในการตรวจสอบ ชื่อที่ตรงกันเพียงอย่างเดียวไม่ยืนยันความต่อเนื่อง ความสัมพันธ์ที่ไม่แน่ชัดต้องมีการตรวจทาน

ตั้งค่า signing_secret และทำตามเอกสารตรวจสอบการส่ง webhook UnifyPort ไม่มี REST API สำหรับอ่านประวัติข้อความ และไม่รับประกันการส่งอีเวนต์ที่พลาดไปอีกครั้ง รายการบทสนทนาปัจจุบันจึงไม่สามารถสร้างข้อความที่หายไปหรือความสัมพันธ์การย้ายที่ไม่ได้ระบุในเอกสารขึ้นมาได้

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

ต้องเปลี่ยน webhook URL หลังกลุ่มเป็นซูเปอร์กรุ๊ปหรือไม่?

รหัสแชตใหม่เป็นเรื่อง routing ไม่ใช่หลักฐานว่าต้องเปลี่ยน URL ให้ตรวจอัปเดตที่ได้รับและปลายทางที่บันทึกก่อน

คำนวณรหัสใหม่จากรหัสเก่าได้หรือไม่?

ใช้ฟิลด์การย้ายที่ Telegram ให้มา อย่าสร้างปลายทางด้วยการเติม prefix หรือเปลี่ยนตัวเลข

ควรย้ายประวัติทั้งหมดไปใช้ chat ID ใหม่หรือไม่?

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

UnifyPort ส่งฟิลด์การย้ายของ Bot API โดยอัตโนมัติหรือไม่?

สัญญาสาธารณะไม่ได้ระบุพฤติกรรมนี้ ให้ตรวจรหัสของบัญชีที่เชื่อมต่อผ่าน API ของ UnifyPort เอง และทบทวนการจับคู่ที่ไม่แน่ชัด

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

ตรวจว่าตัวส่งค้นหาปลายทางเมื่อใด โดยเฉพาะงานในคิว สำหรับการตรวจสอบบัญชีที่เชื่อมต่อ เริ่มจากรายการบทสนทนา

• Telegram Bot API: Message และ ResponseParameters ตรวจสอบเมื่อ 2026-09-21
• เอกสารอีเวนต์มาตรฐานของ UnifyPort