fix(octo): ignore bot's own echoes and non-conversation channels inbound#31
Merged
Merged
Conversation
Discovered while debugging a real binding: the inbound hub dispatched two kinds of traffic that aren't user messages, each producing a bogus 'needs binding' outcome and a failed binding-prompt send: 1. The bot's own outbound messages echo back on its socket (from_uid == robot id). Every agent reply looped in as a new unbound-user message; the replier then tried to DM the binding link to the bot itself → 'not_friend'. The reference channel filters from_uid == robotId in processMessage; we did not. 2. Octo emits system/command channels (channel_type 8 'systemcmdonline' on connect, empty from_uid) that slip past the group-mention gate and got an unsolicited prompt → 'missing sender uid'. Fix: in hub.onMessage, before any dedup/dispatch/audit, drop messages where from_uid == inst.RobotID, and drop any channel type that isn't a real conversation (DM / group / topic) via isConversationChannel. Both dropped silently — not user traffic, so no audit row or dedup churn. Real user DMs still dispatch (verified end to end). Tests: TestHub_IgnoresSelfAndSystemMessages + TestIsConversationChannel. vet + -race clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem (found while completing a real Octo binding)
The inbound hub dispatched two kinds of traffic that aren't user messages, each producing a bogus
needs_bindingoutcome and a failed binding-prompt send (thenot_friend/missing sender uiderrors in the logs):from_uid == robot_id). Every agent reply looped back in as a new "unbound user" message; the replier then tried to DM the binding link to the bot itself →err.server.bot_api.not_friend.channel_type 8systemcmdonlineon connect (emptyfrom_uid); these slipped past the DM/group-mention gate and got an unsolicited "please bind" reply →missing sender uid.Both are confirmed against the reference channel implementation (
cc-channel-octoprocessMessage), which filtersfrom_uid === robotIdand gates on a supported channel type — guards we were missing.Fix
In
hub.onMessage, before any dedup / dispatch / audit work:from_uid == inst.RobotID(self-echo / reply loop);isConversationChannel.Both are dropped silently — they're not user traffic, so no audit row, no dedup churn, no spurious binding prompt. Real user DMs (
from_uid= the human uid, type DM) are unaffected and still dispatch.Verification
octo_chat_session_binding+assistantmessages exist) — unaffected by this change.TestHub_IgnoresSelfAndSystemMessages: self (from_uid==robot) and a type-8 system message are dropped (no Handle, no replier), while a real DM is dispatched.TestIsConversationChannel: DM/group/topic supported; type 8 / 0 rejected.go vet+go test -raceon the octo package clean.