Tại sao bot Twitch bỏ qua tin nhắn của kiểm duyệt viên

Trước tiên hãy xác định tin nhắn biến mất ở giai đoạn nào

Kiểm tra xem bot có nhận được tin nhắn thông thường trong cùng kênh đó không. Nếu trong log không có cả người xem lẫn kiểm duyệt viên, vấn đề thường nằm ở xác thực, kết nối chat hoặc tên kênh. Nếu thấy người xem nhưng không có tin nhắn của kiểm duyệt viên, hãy tìm nguyên nhân trong bộ lọc vai trò, thẻ IRC hoặc đăng ký EventSub.

Đừng chỉ nhìn vào phản hồi của bot trong chat mà hãy xem nhật ký sự kiện đến. Tin nhắn có thể đến được ứng dụng nhưng không kích hoạt lệnh do tiền tố, thời gian chờ, từ khóa chặn, danh sách bỏ qua hoặc kiểm tra quyền. Để kiểm thử, hãy gửi từ người xem và kiểm duyệt viên cùng một câu ngắn giống nhau, sau đó cùng một lệnh giống nhau.

Kiểm tra kênh, tài khoản bot và kết nối IRC

Đảm bảo bot đã vào đúng kênh cần thiết và dưới tài khoản phải đọc chat. Sau khi đổi tên kênh, đổi login hoặc chuyển giữa môi trường thử nghiệm và môi trường thật, ứng dụng có thể vẫn online nhưng lại lắng nghe một chat khác.

Trong log kết nối phải thấy được xác thực thành công, nick của bot và lệnh vào kênh. Sau khi mất kết nối, không chỉ kiểm tra các lần thử kết nối lại mà cả việc đăng nhập lại thành công. Tự động kết nối lại mà không ghi lỗi sẽ che giấu token hết hạn, mật khẩu OAuth sai hoặc lỗi trong tên kênh.

Kiểm tra token OAuth và quyền đọc

Token phải thuộc về tài khoản mà bot dùng để đọc chat. Đừng nhầm nó với token của streamer: quyền của chủ kênh không được truyền cho tài khoản bot riêng. Để đọc tin nhắn qua IRC cần scope chat:read.

Nếu tin nhắn được nhận qua EventSub, sự kiện chat cần token người dùng có quyền user:read:chat. Tùy theo sơ đồ xác thực và ai tạo đăng ký, cũng có thể cần quyền để bot truy cập kênh, bao gồm channel:bot. Đừng thêm scope một cách ngẫu nhiên: hãy đối chiếu chúng với sơ đồ đăng ký hiện tại và tài khoản đứng tên tạo đăng ký.

Có thể kiểm tra tính hợp lệ của token người dùng và danh sách quyền đã cấp bằng yêu cầu:

curl -H "Authorization: OAuth $BOT_OAUTH_TOKEN" https://id.twitch.tv/oauth2/validate

Trong phản hồi, hãy kiểm tra login, ID người dùng, thời hạn và mảng scopes. Nếu thiếu chat:read hoặc user:read:chat, sẽ cần xác thực lại với bộ quyền cần thiết. Nhược điểm của giải pháp này là phải thay token cũ và phiên đã lưu trong cấu hình bot, nếu không bot sẽ tiếp tục chạy với quyền cũ.

Tách riêng chẩn đoán IRC và EventSub

IRC và EventSub chuyển tin nhắn theo các đường khác nhau. IRC truyền luồng chat qua kết nối thường trực: trong log thô cần tìm dòng PRIVMSG từ kiểm duyệt viên. EventSub chuyển sự kiện channel.chat.message qua đăng ký API đã tạo: ở đây kiểm tra trạng thái, condition và transport giao nhận của nó.

Nếu bot dùng cả hai nguồn, hãy ghi nguồn của từng sự kiện vào log. Nếu không, một tin nhắn có thể bị xử lý hai lần, còn sự cố của một transport sẽ không bị phát hiện. Nếu chỉ dùng EventSub, việc không có kết nối IRC không được coi là lỗi. Nhược điểm của sơ đồ EventSub là khi đăng ký sai hoặc bị tắt, bot sẽ không thấy tin nhắn nào cả, ngay cả khi token vẫn hoạt động.

Kiểm tra đăng ký EventSub cho tin nhắn chat

Trong danh sách đăng ký, hãy tìm sự kiện channel.chat.message. Bản ghi phải có trạng thái hoạt động. Trong condition, kiểm tra broadcaster_user_id — là ID kênh của streamer — và user_id của người nhận sự kiện. Lỗi ở bất kỳ ID nào trong số này thường biểu hiện như việc thiếu tin nhắn một cách chọn lọc.

Hãy yêu cầu danh sách đăng ký qua GET /helix/eventsub/subscriptions. Trong phản hồi, kiểm tra type, status, condition và transport. Trạng thái enabled nghĩa là đăng ký đang hoạt động; thông báo về sự cố giao nhận, bản ghi đã xóa hoặc kênh khác sẽ chỉ ra nguyên nhân. Với yêu cầu này, hãy dùng token và Client ID của ứng dụng đã tạo đăng ký.

Đừng chỉ dựa vào việc có bản ghi trong bảng điều khiển hoặc cơ sở dữ liệu của bot. Đăng ký có thể đã được tạo cho kênh thử nghiệm, bị xóa sau lỗi giao nhận hoặc thuộc về ứng dụng khác. Nhược điểm của việc kiểm tra qua API là nó hiển thị cấu hình đăng ký nhưng không giải thích logic lọc bên trong chính bộ xử lý.

Bật thẻ IRC và kiểm tra vai trò của tác giả

Nếu việc kiểm tra quyền dựa trên IRC, client phải yêu cầu capability twitch.tv/tags. Không có thẻ, bot có thể nhận được văn bản và nick tác giả nhưng không thấy các trường mod và badges. Khi đó các lệnh thông thường vẫn đến, còn quy tắc dành cho kiểm duyệt viên lại từ chối sai.

Trong tin nhắn thô của kiểm duyệt viên, hãy tìm mod=1 và badges=moderator/1. Trường user-type có thể không tồn tại, rỗng hoặc không khớp với vai trò hiện tại, vì vậy đừng dùng nó làm dấu hiệu duy nhất. Bộ phân tích phải xử lý đúng các giá trị thẻ rỗng và ký tự được escape; nhược điểm của cách tiếp cận IRC chính là phải tự phân tích định dạng này.

Nếu không có mod=1, trước tiên hãy đảm bảo capability cho thẻ thực sự đã được server xác nhận, chứ không chỉ được client gửi đi. Sau đó kiểm tra badges. Giá trị moderator/1 nghĩa là kiểm duyệt viên, broadcaster/1 là chủ kênh. VIP thường có badge vip/1, nhưng VIP không tự động trở thành kiểm duyệt viên. Không nên coi streamer và VIP là kiểm duyệt viên dựa trên nick, màu sắc hoặc display-name: hãy xác định vai trò theo badges và các quy tắc truy cập riêng.

Kiểm tra quy tắc vai trò trong mã và cấu hình

So sánh các sự kiện thô từ người xem, VIP, kiểm duyệt viên và chủ kênh với cùng một văn bản. Nếu sự kiện từ kiểm duyệt viên đã đến ứng dụng nhưng bộ xử lý bỏ qua nó, lỗi nằm sau khâu nhận: trong kiểm tra vai trò, danh sách đen, chống spam hoặc định tuyến lệnh.

• Đưa login về cùng một kiểu chữ trước khi so sánh.
• Kiểm tra mod=1 và badge moderator, chứ không chỉ một bộ thẻ cố định.
• Xác định riêng quyền cho broadcaster, moderator, vip và tài khoản của chính bot.
• Kiểm tra xem kiểm duyệt viên có nằm trong danh sách bỏ qua, danh sách cấm hoặc danh sách người dùng bị chặn không.
• Xem thứ tự các điều kiện: chống spam hoặc từ khóa chặn có thể kích hoạt trước khi kiểm tra vai trò.
• Đảm bảo lệnh không bị chặn bởi quy tắc dành cho tin nhắn có đề cập, có liên kết hoặc lặp lại văn bản.

Danh sách nick thủ công chỉ phù hợp để chẩn đoán nhanh. Nhược điểm của nó là lỗi thời sau khi thay đổi kiểm duyệt viên, đổi tên tài khoản hoặc thay đổi vai trò trong kênh.

Loại trừ định dạng lệnh, giới hạn và việc bỏ qua ẩn

Bot có thể thấy tin nhắn và cố ý không trả lời. Hãy kiểm tra thời gian chờ của lệnh, giới hạn tin nhắn từ một người dùng, chống lặp lại, bộ lọc emoji và từ khóa chặn. Kiểm duyệt viên thường gửi lệnh nhanh và có thể bị chống spam giống như người xem.

Hãy kiểm thử riêng một câu thông thường và một lệnh có tiền tố. Nếu câu đó có trong log nhưng lệnh không đến được kết quả xử lý, hãy kiểm tra tiền tố, bố cục bàn phím, dấu cách, ký tự vô hình và đối số. Các lệnh có dấu gạch chéo và hành động kiểm duyệt không phải lúc nào cũng đến dưới dạng văn bản thông thường mà bộ xử lý mong đợi.

Ghi lại lý do quyết định cho từng tin nhắn

Để chẩn đoán, hãy lưu thời gian, nguồn sự kiện, kênh, ID tác giả, loại tin nhắn, thẻ và kết quả xử lý. Có thể che văn bản nếu không cần cho việc tìm lỗi. Trong log phải có lý do cụ thể: tin nhắn không được nhận, không nhận diện được vai trò, không qua tiền tố, bị thời gian chờ, người dùng nằm trong danh sách bỏ qua hoặc đăng ký EventSub bị tắt.

Không ghi token OAuth, secret của ứng dụng, địa chỉ webhook và toàn bộ header xác thực vào log thông thường. Những dữ liệu này hữu ích khi gỡ lỗi, nhưng rò rỉ có thể mở quyền truy cập vào bot và cấu hình ứng dụng.

Danh sách kiểm tra chẩn đoán theo thứ tự

1. Gửi cùng một câu và cùng một lệnh từ người xem và kiểm duyệt viên.
2. Kiểm tra log thô và xác định tin nhắn đến qua IRC, EventSub hay cả hai nguồn.
3. Nếu IRC không nhận được tin nhắn, hãy đối chiếu tài khoản bot, tên kênh, token và việc vào chat thành công.
4. Nếu tin nhắn IRC đã đến, hãy đảm bảo thẻ đã được bật, sau đó kiểm tra mod=1 và badges=moderator/1.
5. Nếu không có mod=1, hãy kiểm tra xác nhận twitch.tv/tags và phân biệt moderator/1, vip/1 và broadcaster/1.
6. Kiểm tra token qua validate: với IRC cần chat:read, với tin nhắn EventSub cần user:read:chat.
7. Khi làm việc qua EventSub, hãy kiểm tra channel.chat.message, trạng thái enabled, condition và transport trong danh sách đăng ký.
8. So sánh việc xử lý vai trò, danh sách bỏ qua, chống spam, tiền tố, thời gian chờ và từ khóa chặn.
9. Thêm vào log lý do rõ ràng cho việc mỗi tin nhắn được chấp nhận, bị bỏ qua hoặc bị từ chối.