← Tất cả bài viết
Cẩm nang

Nhóm Telegram chuyển thành siêu nhóm: cập nhật Chat ID an toàn

Khi một nhóm Telegram chuyển thành siêu nhóm, bot phải dùng mã chat mới cho những lần gửi tiếp theo. Bot API cung cấp migrate_to_chat_idmigrate_from_chat_id trong tin nhắn dịch vụ, đồng thời có thể trả về parameters.migrate_to_chat_id trong phản hồi của yêu cầu API không thành công. Hãy lưu rõ quan hệ giữa ID cũ và ID mới: cập nhật định tuyến cho lần gửi sau, nhưng giữ nguyên mã chat gốc của tin nhắn đã lưu.

Điểm chính

  • Chuyển nhóm làm thay đổi định danh đích gửi, không đồng nghĩa với lỗi chuyển giao webhook.
  • Đọc trường chuyển nhóm có cấu trúc, không dò chuỗi mô tả lỗi hay đoán ID mới.
  • Giữ lịch sử theo chat gốc và xác định đích hiện tại ngay trước khi gửi.
  • Lược đồ sự kiện công khai của UnifyPort không mô tả ánh xạ chuyển nhóm tương đương; đừng mặc định có các trường Bot API này.

migrate_to_chat_id và migrate_from_chat_id có nghĩa gì?

Tài liệu Bot API chính thức của Telegram định nghĩa hai trường tùy chọn trong Message và trường đích chuyển nhóm trong ResponseParameters.

Bằng chứngChat cũChat mới
Tin nhắn chứa migrate_to_chat_idchat.id của tin nhắn đómessage.migrate_to_chat_id
Tin nhắn chứa migrate_from_chat_idmessage.migrate_from_chat_idchat.id của tin nhắn đó
Phản hồi thất bại chứa parameters.migrate_to_chat_idID chat dạng số trong yêu cầu gốcparameters.migrate_to_chat_id

Với trường hợp phản hồi API, cần giữ ngữ cảnh yêu cầu gốc. Nếu bạn gửi tới tên người dùng thay vì ID dạng số đã lưu, đừng tự tạo ID số của chat cũ chỉ từ lỗi đó.

Telegram lưu ý các mã chuyển nhóm có thể vượt 32 bit có nghĩa, nhưng tối đa là 52 bit. Có thể lưu bằng số nguyên có dấu 64 bit hoặc số dấu phẩy động độ chính xác kép. Kiểm tra toàn bộ luồng để loại bỏ phép chuyển về 32 bit. Chuỗi thập phân cũng là một lựa chọn thiết kế cho khóa nội bộ, miễn là giữ chính xác dấu và giá trị.

Bài này giả định cập nhật đã tới bộ nhận. Nếu bạn còn đang chọn loại tài khoản và cách nhận, hãy xem Telegram Bot API webhook so với webhook đầu vào hợp nhất trước.

Dùng ánh xạ đích gửi, không viết lại lịch sử

Thiết kế ứng dụng được khuyến nghị là tách hội thoại nghiệp vụ khỏi đích gửi trên nền tảng. Lưu ánh xạ ID cũ sang ID mới trong phạm vi tenant và tích hợp bot, kèm bằng chứng xác lập quan hệ. Đây là khái niệm lưu trữ nội bộ, không phải trường bổ sung của Telegram API.

Không thay thế hàng loạt ID chat trong bản ghi lịch sử. Telegram quy định message_id là duy nhất trong chat chứa nó, không phải trên toàn hệ thống. Gán lại tin nhắn cũ sang chat mới có thể tạo liên kết sai. Quan hệ giữa hai đích gửi không phải cam kết về phép chuyển đổi mã tin nhắn.

Trình tự nên áp dụng:

  1. Xác thực nguồn và lưu bền vững cập nhật nhận được. Nếu bằng chứng là lỗi API, lưu phản hồi thực tế cùng yêu cầu gốc.
  2. Lấy mã chat cũ và mới theo bảng trên.
  3. Nếu hệ thống lưu trữ hỗ trợ, ghi ánh xạ và cập nhật đích hiện tại trong cùng một giao dịch.
  4. Bằng chứng lặp lại cho cùng một cặp không tạo thêm hành động. Tách các ánh xạ mâu thuẫn hoặc tạo vòng lặp để kiểm tra, thay vì âm thầm ghi đè.
  5. Giữ nguyên lịch sử. Với tác vụ trong hàng đợi, tra đích hiện tại ngay trước khi gửi.

Phối hợp việc cập nhật ánh xạ và đọc đích gửi bằng khóa ứng dụng hoặc cơ chế kiểm soát đồng thời tương đương. Nếu không, một worker có thể vừa đọc ID cũ thì worker khác đã chốt chuyển nhóm. Ngay cả khi có phối hợp nội bộ, vẫn cần xử lý lỗi gửi do tình huống cạnh tranh này.

Khôi phục tác vụ trong hàng đợi mà không gửi lại mù quáng

Phản hồi không thành công chứa parameters.migrate_to_chat_id cung cấp đích mới. Lưu nó trước khi cân nhắc thử lại, rồi kiểm tra tác vụ còn phù hợp để thực hiện hay không. Hết thời gian chờ mạng là trường hợp khác: nó không chứng minh đã chuyển nhóm, cũng không chứng minh lần gửi đã thất bại.

Nếu tác vụ tham chiếu một tin nhắn trước đó, đừng đơn giản ghép message_id cũ với ID chat mới. Xác minh tham chiếu còn hợp lệ hoặc chuyển tác vụ sang kiểm tra thủ công. Không âm thầm đổi một hành động phụ thuộc ngữ cảnh thành tin nhắn thông thường khác.

Để theo dõi kết quả gửi, xem trả lời trong webhook và gọi sendMessage riêng. Xác nhận đã nhận đầu vào không có nghĩa là tác vụ gửi ra đã hoàn tất.

Các tình huống nghiệm thu đề xuất dưới đây không phải kết quả đã đo:

  • Bằng chứng chuyển nhóm lặp lại chỉ giữ một ánh xạ và không tạo tác vụ gửi thứ hai.
  • Cập nhật từ chat cũ đến muộn vẫn giữ nguồn gốc lịch sử, không đổi đích hiện tại về ID cũ.
  • Ánh xạ mâu thuẫn tạm dừng các tác vụ liên quan.
  • Chat không liên quan nhưng trùng tên không bị gộp.
  • Mã định danh không bị cắt bớt khi tuần tự hóa và đọc ghi cơ sở dữ liệu.

Ranh giới của UnifyPort

Giao diện không chính thức của UnifyPort sử dụng message.received với provider, account_iddata.conversation.id. Hãy giữ các mã này trong không gian tên riêng, thay vì giả định có thể thay trực tiếp bằng Bot API chat ID. Khi xây dựng bộ nhận chung cho Telegram, WhatsApp hoặc Zalo, việc dùng chung lược đồ không làm các mã định danh có thể thay thế cho nhau.

Tài liệu sự kiện công khai không định nghĩa migrate_to_chat_id, migrate_from_chat_id hay bảo đảm cung cấp ánh xạ trước và sau chuyển nhóm. Không xem group.updated hoặc conversation.updated là bảo đảm đó. Với tài khoản nhắn tin Telegram đã kết nối, hãy kiểm tra hợp đồng API danh sách hội thoại và dùng conversation_id được trả về để đối soát. Trùng tiêu đề không đủ chứng minh tính liên tục; quan hệ chưa rõ cần được kiểm tra.

Khi nhận sự kiện, cấu hình signing_secret và làm theo tài liệu xác minh webhook. UnifyPort không có REST API đọc lịch sử tin nhắn và không bảo đảm phát lại sự kiện bị lỡ. Danh sách hội thoại hiện tại không thể tái tạo tin nhắn đã mất hay cung cấp quan hệ chuyển nhóm chưa được tài liệu hóa.

Câu hỏi thường gặp

Có cần đổi webhook URL sau khi nhóm trở thành siêu nhóm không?

ID chat mới là vấn đề định tuyến, tự nó không phải bằng chứng cần đổi URL. Kiểm tra cập nhật nhận được và đích đã lưu trước.

Có thể suy ra ID mới từ ID cũ không?

Hãy dùng các trường chuyển nhóm do Telegram cung cấp. Không tạo đích bằng cách thêm tiền tố hoặc sửa chữ số.

Có nên chuyển toàn bộ lịch sử sang chat ID mới không?

Không. Giữ cặp chat và tin nhắn gốc. Liên kết hội thoại ở tầng ứng dụng mà không coi mã tin nhắn đã được chuyển đổi.

UnifyPort có tự động cung cấp trường chuyển nhóm của Bot API không?

Hợp đồng công khai không mô tả hành vi đó. Đối soát mã của tài khoản đã kết nối qua API riêng của UnifyPort và kiểm tra ánh xạ chưa chắc chắn.

Bước tiếp theo và nguồn

Kiểm tra thời điểm bộ gửi xác định đích, đặc biệt với tác vụ đang chờ. Để đối soát tài khoản đã kết nối, bắt đầu từ List conversations.

UnifyPort API

Biến tích hợp nhắn tin thành một pipeline sản phẩm ổn định.

Bắt đầu bằng cách gửi qua một API, rồi đưa mọi tin nhắn inbound trở lại hệ thống kinh doanh bằng sự kiện chuẩn.