Can the Pipedream Team Resolve the Inaccuracy of the Slackbot's 'is_bot' Parameter Causing an Infinite Loop?

This topic was automatically generated from Slack. You can find the original thread here.

Hi Team,
I’m reaching out to report an issue I’ve encountered with the Pipedream Slackbot application. It appears that when the bot posts to Slack, it’s sending the parameter "is_bot": "false" which is causing a bit of a problem.
Since Slack is interpreting these posts as being from a human user rather than a bot, we’re ending up with an infinite loop situation. The Slackbot’s reactions are treated as user messages, triggering further responses and so on, endlessly.
I’ve looked into this, and it seems that there’s no straightforward way to adjust this setting on my end. It looks to be tied in with the bot’s authentication level, which isn’t something I can change through configuration.
I really want to avoid having to rewrite our setup in Node.js just to alter this parameter. So, I’m wondering if someone on the Pipedream team could help us out here. Is there any chance that we could get an update to resolve this?
Your assistance is greatly appreciated as this loop is affecting our workflow. If there’s any additional information required or if there’s a workaround I haven’t considered, please let me know.
Thanks for your time and help!

Hey , would you mind share the screenshot of you Slackbot action configuration?

I tried to reproduce your issue as below:

  1. Setup a new Slack - Message In Channels trigger (1st image below)
  2. Use Pipedream Slack Bot - Send Message public channel action to send a message (2nd image below)
  3. I observed that the event in the trigger did not contain the authorization object as yours, but the bot_id
    Where did you get the object in your image?

i need to send a direct message from a user=>app conversation

could you share more information for me to reproduce your issue?

And which trigger are you using to listen on messages? I’m not sure I have all information to support this case

Testing Pipedream send direct message and Pipedream trigger - New Direct Message shows all information, including the bot_id which you can use to determine if this is from a bot or not

From what I understand, the “is_bot” value is transmitted by the slackbot authentication part directly from pipedream, so this parameter won’t be visible in the step’s JSON stream output.

My problem is that when my bot responds to a direct message, my bot’s message is sent with “is_bot”: “false” and so this activates the user message event, which returns a call to my webhook which itself regenerates a message that is sent and so on in a loop.

To avoid entering this loop, the message would have to be sent with “is_bot”: “true” so that the message isn’t caught by the event and doesn’t trigger a call to the webhook.

Could you try to make a simple scenario that receives a direct message to the application, then sends the same message back from the application as a direct message, and tell me if you can do it without making an infinite loop?

Translated with DeepL.com (free version)

I can see that the is_bot variable is set to false because it’s visible in the data received by the webhook just after the first message is sent, which is where the loop begins.

Hi , I’m not sure I’m following what you mean. Where do you get the webhook? Is it via your server or Pipedream Slack Triggers?

it looks like you’ve configured a webhook trigger in your workflow. So my guess is you’ve taken the https://*.[m.pipedream.net/](http://m.pipedream.net/) URL from the trigger, and entered it into your Slack App Event Subscription Configuration (https://api.slack.com/apps/YOUR_APP_ID/event-subscriptions) page. This would be the reason you’re receiving the authorizations field in the event that’s getting triggered (more info on this field in slack docs, unfortunately I don’t see any explanation of what is_bot represents).

The down-side of this approach is that your trigger will potentially receive multiple Slack Events for every action that takes place in your Slack Workspace. This will be very noisy (and costly in terms of credits), and you’ll have to filter out messages you don’t actually care about.

It’s likely that in your example above, the data that you’re showing is for a different event, and not specifically the message that your bot sent. Note that the type of your event is event_callback. Typically in this approach you should be filtering for message types.

My first suggestion would be to instead change your workflow trigger to an actual slack trigger.

image.png

The event shape of this trigger will be much different than in the other approach, you can select one that’s scoped down more closely to what you need, and you should get the correct user id/type.