Remove bot_message and me_message from supported_message_subtypes
Closed this issue · 7 comments
Context: In litaio/lita#191 @jimmycuadra suggested modifying lita-slack to ignore bot messages automatically as a simpler alternative to a configurable ignore list. While following up on this suggestion, I discovered here (
) that the adapter already checks the message subtype (https://api.slack.com/events/message) and allowsbot_messages and me_messages to be dispatched to the robot.
I can't think of a particular scenario where this behavior is actually desirable:
- In my experience, a user who wishes to send a message or command to be received by the bot will not attempt to do so with a
/memessage. In fact, a Lita response to a/memessage is usually unexpected. - The reason given for ignoring messages from self (preventing infinite loops, see https://github.com/litaio/lita/blob/c3ae7d0d994fd0f15f5f18290920b49ca7e3441b/lib/lita/route_validator.rb#L55) also applies to messages from bots in general. For example, I added the
ignoreconfiguration option to lita-jira (esigler/lita-jira@7f8fda2) precisely because our Lita instance was responding to JIRA issue IDs it detected in messages sent by our JIRA Slack integration, resulting in spammy duplicate output.
For these reasons, I am proposing the removal of bot_message and me_message from the array of supported_message_subtypes. Pending feedback, I can submit a pull request enacting this change.
I'm +1 on removing bot messages and -1 on removing me messages. A message sent by another bot will never be intended to trigger a Lita route. If someone wants to integrate Lita with an external service, it should be done via explicit web hooks, not by passing messages through chat. For me messages, I see this more as a different presentation style for a message sent by a human, and so we shouldn't assume the user's intent. For example, "/me does thing" and "I did thing" are semantically the same. The differene is only in how the person chooses to express themselves. I agree that it's unlikely a me message would be intended to trigger a command route, but there are also the less common message routes that should still pick up matching patterns anywhere in messages (think lita-karma).
Closed by #95.
Damn. This broke our lita-bot. We have librato report to an #alerts channel. At certain thresholds (e.g. no one is responding), librato issues a HELPPPPP alert in which lita responds by restarting our servers. The librato message is a bot_message.
Sorry, Eric. I suppose technically this was a breaking change, but I'm didn't think anyone actually had Lita listen to non-human input intentionally. It'd definitely be a more robust approach to use a web hook for the kind of integration you describe.
It may be worth making this configurable in order to support different use cases. Thoughts, @jimmycuadra?
On Sep 1, 2016, at 11:22 AM, Eric Boehs notifications@github.com wrote:
Damn. This broke our lita-bot. We have librato report to an #alerts channel. At certain thresholds (e.g. no one is responding), librato issues a HELPPPPP alert in which lita responds by restarting our servers.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Scratch that, I posted before seeing the related pull request.
On Sep 1, 2016, at 11:22 AM, Eric Boehs notifications@github.com wrote:
Damn. This broke our lita-bot. We have librato report to an #alerts channel. At certain thresholds (e.g. no one is responding), librato issues a HELPPPPP alert in which lita responds by restarting our servers.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Thanks Slack support for pointing me to this page after I asked them why bot cannot see messages from other bot 😕
So, those who want this can fork and git revert a233d14e1932090fde649d0919b547bfc2fd416b, because it seems not to be configurable.