Hubot-slack: Hubot is talking to itself

[asagage]

• [X] I've read and understood the Contributing guidelines and have done my best effort to follow them.
• [X] I've read and agree to the Code of Conduct.
• [X] I've searched for any related issues and avoided creating a duplicate issue.
  

  Description

My hubot (named bb8) seems to be responding to it's own messages. For example, on a vanilla install, if I type: "bb8 help" it responds with the normal help text, but then it also returns a ship it squirrel because it parsed the help text itself.

Reproducible in:

hubot-slack version: 4.0.2

Steps to reproduce:

1. Install hubot
2. connect to slack with a token for a hubot integration user named "bb8"
3. join a channel and invite bb8
4. send the message "bb8 help"
   

   Expected result:

only the help text is returned

Actual result:

help text is returned followed by a ship it squirrel

[iancward]

@asagage I think this is an issue with the hubot-shipit script: https://github.com/hubot-scripts/hubot-shipit/issues/4

In my installation, I've disabled the shipit script (and anything that "hears" instead of "responds").

[iancward]

Unless this is broken: https://github.com/slackhq/hubot-slack/blob/master/src/bot.coffee#L119-L120

[DEGoodmanWilson]

This was a problem in the past, it _should_ be sorted by those lines highlighted by @iancward . @asagage can you confirm that this is still an issue with the hubot-shipit script disabled?

[iancward]

I'm using version 4.0.2 of hubot-slack and version 0.2.0 of hubot-shipit, and I had to go to external-scripts.json to remove hubot-shipit because the bot was responding to something that it posted.
I think this might actually be caused by https://github.com/slackhq/hubot-slack/issues/344 or similar, since hubot-help sends formatted text to Slack; it gets printed in slack as coming from a user with name "bot" and the generic hubot icon. This is what's probably causing the bot to respond, as it doesn't _appear_ to be coming from itself.

[DEGoodmanWilson]

@asagage Is this still an issue for you, or have we resolved it?

[lobeck]

All the important fixes for is renamed hubot instances were commited after the last release, so it would be great if you publish a new one, so we don't need to pin commit ids anymore.

[DEGoodmanWilson]

Will do that by end of day.

[iancward]

@DEGoodmanWilson based on my notes above, this is still an issue with version 4.0.2 of hubot-slack; I believe the problem is caused by https://github.com/slackhq/hubot-slack/issues/344
Essentially, the hubot-help script formats some HTML and then sends it to the Slack adapter, which is posted as coming from the generic "hubot" user (with default icon). Since the message is posted by "bot" instead of the bot's name, https://github.com/slackhq/hubot-slack/blob/master/src/bot.coffee#L119-L120 doesn't come into play.

[DEGoodmanWilson]

Good news is that #344 should be fixed by a recent PR that @johnagan submitted and that I merged. Let's see if that is so! I'm going to do a release, could y'all check?

[iancward]

@DEGoodmanWilson I don't have any issues with 4.0.4. I re-enabled hubot-shipit and it the shipit script isn't triggered when the bot posts the help message. I think this is good to close.

[DEGoodmanWilson]

Great!

[p00j4]

I have got into the similar problem but i'm using slacker to post message with enabled as_user=True which lets message to appear in window of hubot user itself. now the moment I get the message, it tries to reply back on its own message. Has it also to be fixed at slack post message level? 💭 or there is any message revert type in hubot i can use, reply only if user is not "hubot" or as work around, i'll have to add if check everywhere in script to do that.

PS. note res.message.user.name comes as undefined in this case, may be thats why hubot responds back

[aoberoi]

@p00j4 i'm not exactly sure what you're describing. can you help clarify?

it sounds like you're using 2 different processes (one written with slacker, one written with this hubot-slack adapter) but sharing the same tokens with both. is that right?

i can't say much for the slacker side of this problem, but i wanted to point out that Authorship is a little more complicated than just whether as_user is true or false. the fact that the message appears as a DM from the App (which is what i see in the screenshot) sounds like as_user is actually false. what type of token are you using? what scopes does it have?

[p00j4]

@aoberoi yes true. its the same token on hubot which i'm using with slacker. when a message is posted to any of the team-mate, using slacker with as_user "true", the message appears in the team-mates hubot window like shown in the screenshot.
the 1st line is the posted message. second line is hubot reverted (bcz in no match case, script returns "sorry")
the reason I have understood is - 'res.message.user.name' comes as undefined in this case, may be that is why, hubot responds.
This looks like a tech limitation and I find can't be solved at hubot or slacker level hence I'm dealing with user.name check. Just wanted to confirm if there was already something thought of for such case.