Phải làm gì khi chatbot trả lời hai lần khi phát trực tiếp

Trước tiên hãy xác định loại trùng lặp

Hai câu trả lời giống nhau liên tiếp không phải là một lỗi duy nhất mà là ít nhất hai lỗi khác nhau. Trường hợp thứ nhất: bot nhận được một sự kiện nhưng nhận hai lần. Trường hợp thứ hai: sự kiện chỉ đến một lần nhưng bot gửi đi hai lần. Cách khắc phục hai trường hợp này khác nhau, nên đừng bắt đầu bằng việc sửa mã — hãy bắt đầu từ log.

Mở nhật ký của bot và tìm thời điểm xảy ra trùng lặp. Sau đó xem hai trường: mã định danh sự kiện và thời gian nhận.

• Hai yêu cầu có cùng event_id (hoặc message_id, notification_id — tên gọi tùy thuộc vào nền tảng) và chênh lệch nhau vài mili giây — đây là việc gửi lại cùng một sự kiện. Hãy tìm cơ chế chống trùng lặp.
• Hai yêu cầu có mã định danh khác nhau — thực sự có hai trình xử lý đang đăng ký vào kênh. Hãy tìm đăng ký thứ hai.

Nếu hoàn toàn không có log, hãy bắt đầu từ bảng điều khiển của nền tảng: ở đó có thể thấy ai đang đăng ký nhận sự kiện của kênh.

Đăng ký trùng trong bảng điều khiển trông như thế nào

Các nền tảng không hiển thị “bot được kết nối hai lần” trên một dòng. Các dấu hiệu nằm rải rác ở nhiều mục khác nhau.

Twitch

Kiểm tra mục Connections trong cài đặt tài khoản — ở đó có danh sách các ứng dụng đã kết nối. Cùng một bot có thể được ủy quyền vừa như ứng dụng của kênh, vừa như ứng dụng của tài khoản cá nhân bạn. Ngoài ra, các đăng ký EventSub tồn tại riêng: ứng dụng có thể vẫn giữ đăng ký đang hoạt động cho channel.chat.message sau khi bạn đã ngắt tích hợp trong bảng điều khiển. Một bản sao bot thứ hai chạy cục bộ cũng nhận sự kiện ngang với bản đang chạy chính thức.

YouTube

Ở đây thường không phải bản thân bot là thủ phạm mà là quyền truy cập vào chat: bot được kết nối với buổi phát trực tiếp vừa với tư cách người kiểm duyệt, vừa với tư cách tài khoản thành viên riêng biệt. Hãy xem danh sách người kiểm duyệt và danh sách các ứng dụng được ủy quyền của kênh. Riêng một điểm nữa — nếu bot hoạt động qua nhiều dự án Google Cloud, các khóa có thể đi theo hai đường khác nhau.

Discord

Trường hợp rõ ràng nhất: hai ứng dụng có cùng token trên một máy chủ. Cả hai đều thấy tin nhắn trong kênh và cả hai đều trả lời. Hãy kiểm tra danh sách bot trên máy chủ và đảm bảo rằng không có webhook thứ hai cùng tên được kết nối vào kênh.

Nhược điểm của cách này là cần quyền truy cập không chỉ vào bot mà còn vào bảng điều khiển của kênh. Nếu kênh do nhiều người quản lý, bản sao thứ hai có thể do người khác khởi chạy mà bạn không biết.

Webhook lặp lại: vì sao sự kiện đến hai lần

Dịch vụ bên ngoài gửi webhook và chờ xác nhận. Không nhận được xác nhận trong thời gian quy định — sẽ gửi lại lần nữa. Yêu cầu thứ hai mang cùng sự kiện đó, nhưng bot lại coi đó là sự kiện mới và trả lời lần nữa. Điều này xảy ra khi máy chủ bị treo bất kỳ lúc nào: tải càng lớn thì càng thường xuyên.

Cách khắc phục là chống trùng lặp ở phía bot. Cần một khóa giống nhau cho tất cả các bản sao của cùng một sự kiện và duy nhất cho các sự kiện khác nhau. Khóa được lấy từ phần thân yêu cầu hoặc từ header — điều này phụ thuộc vào API, nhưng nguyên tắc thì giống nhau.

Ví dụ về khóa chống trùng lặp

Hãy hình dung một webhook về khoản donate mới. Trong phần thân có một đối tượng với trường id — số giao dịch duy nhất, không thay đổi khi gửi lại. Logic như sau:

1. Khi nhận yêu cầu, lấy id từ phần thân.
2. Kiểm tra trong kho lưu trữ (Redis, bảng trong cơ sở dữ liệu) xem nó đã xuất hiện trong khoảng, ví dụ, một ngày qua chưa.
3. Nếu đã xuất hiện — trả lời dịch vụ là “đã nhận” và không gửi gì vào chat.
4. Nếu chưa — ghi lại và xử lý như bình thường.

Khóa phải lấy từ chính sự kiện, chứ không phải do bạn tự tạo: nếu tự tạo, hai lần gửi của cùng một sự kiện sẽ có khóa khác nhau và cơ chế chống trùng lặp sẽ không hoạt động. Một số nền tảng cung cấp sẵn header chứa mã định danh lần gửi — khi đó hãy dùng nó, sẽ đáng tin cậy hơn. Nhược điểm của cách này là cần kho lưu trữ và chính sách dọn dẹp, nếu không cơ sở dữ liệu khóa sẽ tăng vô hạn.

Nếu trùng lặp đến từ hai nguồn khác nhau

Một trường hợp riêng — khi sự kiện không bị lặp lại mà thực sự đến từ hai nơi. Điển hình: bot trả lời lệnh cả trong chat lẫn trong tin nhắn chuyển tiếp giữa các nền tảng qua cầu nối. Hoặc tự động trả lời được cấu hình cho hai trigger cùng kích hoạt trên một cụm từ.

Những trùng lặp như vậy khác với webhook lặp lại khi xem log: các yêu cầu có nguồn khác nhau (nền tảng khác nhau, trình xử lý khác nhau), nhưng cùng một sự kiện về mặt ý nghĩa. Hãy tìm chỗ giao nhau của các trigger và tắt một trong số đó. Với cầu nối — đừng chuyển tiếp tin nhắn của chính bot trở lại.

Kiểm tra trước khi phát trực tiếp

1. Gửi một lệnh thử và xem có bao nhiêu câu trả lời được gửi đến.
2. Tắt tất cả các tích hợp trừ một, lặp lại.
3. Bật lần lượt từng cái cho đến khi trùng lặp quay lại — như vậy sẽ tìm ra thủ phạm.
4. Đối chiếu qua log mã định danh sự kiện của cả hai câu trả lời: giống nhau — gửi lại, khác nhau — đăng ký thứ hai.

Nếu không tìm ra nguyên nhân, hãy tắt tự động trả lời cho sự kiện gặp vấn đề và viết cho bộ phận hỗ trợ của dịch vụ kèm log và thời điểm lặp lại. Trong lúc chờ — hãy quản lý chat thủ công: thà mất tự động hóa một buổi tối còn hơn làm ngập buổi phát trực tiếp bằng những câu giống nhau.