I have a flow that relies on the Slack Message Reader as a Trigger but it fails to trigger a run. If I run the flow manually, everything works as expected.
I followed the debugging steps found in this post from some months ago.
I now re-authenticated Slack as mentioned here, but don’t think this is an issue because I just set up the Slack bot 7 days ago and when clicking the “validate auth” button in the node, it says the credential is valid (I did this before re-authenticating just now).
Hey @Elias — Thanks for reporting this. Just to confirm, you’re not seeing any Slack-triggered runs on the history page or in the “Previous Runs” tab on the canvas, right?
Can you also check if there have been three consecutive failed runs from the trigger? If that’s the case, the trigger gets disabled automatically as a precaution.
If neither of those help, could you try deleting the node once, adding it back, and running a quick test for the trigger? We recently shipped major improvements to trigger functionality, so once it’s working again, this issue shouldn’t come up.
Hi!
I do see some Slack-triggered runs over the past day (between the manually triggered runs I was doing). And some of them fail (by design).
At least by the design Gummie helped me come up with .
Since the message I want to listen to, I can’t ignore bot messages.
In order to avoid a recursion effect where the Gumloop message I post triggers the flow again, I go from the Message Reader node into a Filter node which checks whether the message is from the Slack automation bot that sends the new sign up notification to the Slack channel in quesiton.
If that is not the case, the flow fails there (because the filter condition isn’t met).
I was under the impression that this is the best/intended way to solve my recursion issue (again, due to Gummie’s guidance). I guess these failed runs then trigger some sort of action in your backend that disables my trigger?
I have already, multiple times now, followed the debugging steps here (turn off trigger, save, delete node, save, add node, save, enable trigger, save) and have re-authenticated.
I also built the flow only about 5 days ago, so I assume that was after the trigger functionality improvements you mentioned?
Just an hour ago or so another message came in and failed to trigger the workflow.
Is there anything in the filtering/recursion protection design I could adjust?
Now I just got an email that my trigger got deactivated due to 3 consecutive errors in the flow (which were due to me having issues with my slack block kit message formatting).
I am now rebuilding my flow using if/else nodes instead of filters and an output node to exit the flow “gracefully” when the undesired condition is met.
I haven’t completed this yet or done testing, so not sure if this is the final solution. One issue I encountered though, is that I am now shown that I have 2 active Slack Message Reader triggers in my flow, even if I only have one Slack message reader node:
Hey @Elias — Thank you for the context. I’d recommend setting up a subflow and wrapping it with an Error Shield. This way, if the Filter node or any other part of the flow fails, the error will be caught by the shield and your trigger will stay intact.
Looping in @kaustav_gumloop to take a look at the trigger showing up twice.
I think I rebuilt the flow now using a combination of Output nodes and a subflow wrapped in an error shield to ensure a graceful exit under all conditions.
But my problem with the “double trigger” remains.
Another thing I noticed in the previous runs was that the flow did get triggered by messages written in the channel by humans but it did not get triggered by the sign up notification that came in (through slack automations), even though I have “ignore bot messages” turned off.
Generally looking better but still “feels” a bit unreliable at this point
Hey @Elias , we released a fix for this last night. Could you please try reloading your flow pages, and pressing save? If that doesn’t work, delete the trigger node entirely, save, refresh and add it back in. Let us know if that works!
Yes! Now I only have one trigger.
I’ll let it run for a few days now and see if I run into any more problems. Thanks for the helps so far.
Maybe teach Gummie that exiting a flow with an error/crash is not good and that one should always gracefully exist (I asked Gummie about whether aborting the flow with an error is ok and it claimed it was the intended way to handle if/else flows )
Bad-ish news, I am afraid @Wasay-Gumloop .
The flow does get triggered by some messages into the channel (primarily those sent by humans) but does not get triggered by the messages sent via Slack Workflows/Automations (even though I do NOT have the ignore bot messages flag turned on).
I already did the “turn trigger off, save, turn trigger on, save” and “turn trigger off, save, remove slack message reader, save, put everything back and save a lot” algos and neither of them fixed it.
Am I missing something here? Is my flow just cursed and I’ll be forced to re-build it from scratch (please say no )?
Hey @Elias - Thank you for flagging. Can you share what workflows/automations you have set that are sending messages in the channel? A screenshot would be super helpful so I can reproduce this on my end.
I have Outseta send a webhook whenever an account is created. They send a nested JSON, so:
I use pancake.studio to flatten the JSON and pass it on to Slack automations
There I map some basic fields (account name, user first and last name, email, Outseta Uids)
And then send a template message into our notifications channel with some nice buttons to link to the CRM page of the account and person created.
I want the Slack message trigger to react to those messages, do research and enrichment on sign ups from company emails, and post that into the message thread.
The trigger works whenever a “human” posts something into the notifications channel. But bot messages (both from Slack automations and from Gumloop messages (whenever I trigger the flow manually) seem to get ignored, even though the “ignore bot messages” flag is turned off and I have done all of the “turn on, save, turn off, save” and “delete node and do lots of turning off and on and saving” steps I could think of
Appreciate the context! This does seem like a very specific edge case with the app you’re using. I tested the Slack trigger with the Gumloop bot sending a message, as well as a few random apps from the Slack marketplace, and everything worked as expected. I’ll go ahead and create a ticket so we can look into this further—there’s probably a way we can improve how we identify bot messages in the future version of the node, though this might be tricky to reproduce.
That said, and in the meantime, would a webhook trigger work to start the Gumloop flow, since you’re already using the webhook and Slack is acting more like an intermediary here? Here’s the API reference for starting an automation.
Hi Wasay!
Thanks for looking into this more.
I have tried to get this workflow to work with the websocket API but can’t get the inputs to receive the JSON that Outseta sends (I have to use the “one liner” solution since Outseta only takes a webhook URL when setting up their webhooks).
I gave up after trying for about an hour yesterday. I also don’t see the point of writing and running a script that takes the JSON, parses it, and then does a “proper” API call to gumloop (with the inputs specified and broken down).
I’d just want to get the entire JSON into an input and process it in Gumloop with the JSON reader node. But again, that didn’t work for my. I only received an empty response. Here is the workbook where I experimented.
Plus, the value of Gumloop, in my eyes, is that I don’t have to do this but have something like a Slack message trigger built in.