Trigger not activated when message is sent on a Slack channel

Get Help Pipeline Failure
1

We used a slack → AI → news items → slack sort of service for months (maybe a year already), now suddenly the trigger does not work anymore, the flow is not executed. Gummie could not resolve it, moreover gave quite a few bad but time consuming advices. :confused:

Flow:

2

Hey @lacikiszely_AbilityMatrix thanks for flagging this!

I checked the workflow and it looks like it failed for three consecutive runs. When that happens, the trigger is disabled as a precautionary measure. You should have received a trigger deletion email in this case.

For reference, here are the failed runs (you can also find them from the Previous Runs tab):

image
image744×454 18.4 KB

You’ll notice that all of these runs are failing at the Extract Data node step. This is happening because the node is using Gemini 1.5 Pro, which has been deprecated.

If you update the node to use a different model, you should be all set.

Screenshot 2025-10-04 at 6.19.09 AM
Screenshot 2025-10-04 at 6.19.09 AM1056×722 37.3 KB

Let me know if this works for you :slight_smile:

3
  1. Yes, I know the previous runs function, thanks, I use it very often, as it is the most effective debugging tool to see inputs and outputs.
  2. I received an email about “3 consecutive stops”, but it does not point out that a particular AI Engine is not there anymore. (And as far as I remember, the flow did not stop at the same spot)
  3. In most cases it is only a temporary platform or other similar smaller hiccup (eg a connecting line lost), so I never check back every single node. Just reactivate the trigger and then works.
  4. So I reactivated and then such interesting things occur like losing a slack channel (I do not see how that relates to a missing AI engine though)
  5. Before putting that workflow in production (last year?) we have checked multiple AI Engines for output quality + considered our API Key availabilities also, this is why different AIs are used in different roles (eg. 3 or 4 in this flow). If anything changes, it is not that easy for us to follow-up.
  6. I would think if a node does not have an underlying AI Engine anymore, it could and should be checked before running (or saving). The pipeline can not run without the function, will definitely stop when reaching that node, so at least an indication would do good (similarly to content unused and not-connected things you already do)
  7. Now I did another round of updating, selecting engine, authenticating… still does not work: “Application error: a client-side exception has occurred (see the browser console for more information).”
4

Hey @lacikiszely_AbilityMatrix – appreciate the feedback – thank you for that. You’re right, we can improve the UX in a few areas here.

To address your points about the emails after three consecutive failures and the trigger being disabled: we now include the exception error if it’s a node error. Otherwise, if it’s not a node error, the email still includes the run link so the user can investigate further.

Regarding the underlying AI model issue, that’s an unfortunate timing issue – Gemini 1.5 Pro was recently deprecated by Google on September 29th. Since this was an older workflow relying on an older engine, it became susceptible to that deprecation. Now that you’ve updated the model, that issue shouldn’t recur going forward.

As for the client-side exception error, that’s definitely concerning. Could you record your screen using this link please? That’ll help us take a closer look. I’ve also added some credits to your account to make up for the trouble.

5

Thanks for the feedback and explanations!

Recording of client-side exception: done, I could easily replicate, when upgrading Extract Data node from v2 to v3, it happens.

6

Hey @lacikiszely_AbilityMatrix – The client side exception error should now be fixed, really appreciate the patience here!

Let me know if you run into anything else :slight_smile:

7

Still the same flow, checked back if we can use it.
No.
Now the “client side exception” is gone (thanks!), also I can update the nodes.

But the slack reader and writer nodes do not see the needed channel.

I have removed nodes, reauthenticated, consented on Slack, Gumloop is member of the slack channel… still can not select the channel (called #learning_inspiration) in the node, so no chance to pick up the trigger. Last time it worked: 19 September.

8

Hey @lacikiszely_AbilityMatrix – Based on the troubleshooting steps that you’ve already tried there’s one possibility, the slack channel might be in a different Slack workspace compared to the one that is authenticated.

Here’s a tutorial on how to fix it, let me know if that does the trick.

9

Thanks, still can not be the root cause.

  1. Gumloop is a member of the respective slack channel (I can see that in Slack, channel’s integrations, so authentication was appropriate on the other side).
  2. We have only 1 work space allowed for Gumloop’s account, that’s the right one, checked that also (I am personally member in more workspaces, but you can not see them from Gumloop’s auth)
10

Okay that’s interesting. Might need to hop on a quick call to troubleshoot this then, what timezone are you in so I can coordinate this. Feel free to email me if that’s easier – wasay@gumloop.com

11

Thanks, currently on business + family travels, will revert to this when back to normal life in Nov.

12

Returning to that topic with an interesting new occurance:

A simple pipeline, receiving a webhook JSON then sendig it on slack.

Slack Message Sender can pick up the users as recipients (so it is now a Slack DM to me).
Can NOT pick up the channels. Though users are seen, and also the same credentials are in operation in other workflows (so the authentication should be okay, as the exact same shared…).

13

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.