We are using postMessage to send a button with a link. Everything displays fine and the link works as expected, but after clicking our 'View Report' button a warning icon displays as if something is set up incorrectly. I'm not sure if this is a UI bug with blocks or an issue with our postMessage payload.
Here is our payload:
slackWeb.chat.postMessage({
as_user: false,
channel: 'CHANNEL_ID',
text: '',
blocks: [
{
type: 'section',
text: {
type: 'mrkdwn',
text: 'Sample text',
},
accessory: {
type: 'button',
text: {
type: 'plain_text',
text: 'View Report',
},
url: 'http://example.com',
action_id: 'button',
},
},
],
});
We see this issue on the windows and mac slack clients, but not in the iOS app.
x in one of the [ ])x in each of the [ ])Filling out the following details about bugs will help us solve your issue sooner.
Select all that apply:
@slack/web-api@slack/events-api@slack/interactive-messages@slack/rtm-api@slack/webhookspackage version: 5.1.0
node version: 10.14.2
OS version(s): Windows 10, macOS
postMessage payload aboveA warning icon does not display when clicking a button with a URL
A warning icon displays when clicking a button with a URL
On click the loading spinner displays briefly:

After my browser loads the URL, back in slack there's now a warning icon next to the button:

Thanks for filing the issue, @amkoehler. My apologies we didn't get back to you sooner.
I totally expected a button with a URL (rather than an app's own action) to work as you described at first too. However, these buttons actually dispatch a request to your app when a user clicks on them, and Slack expects you to respond to that request with an 200 OK.
If you're using @slack/bolt, then my recommendation is to route the action_id of that button (in your example "button") to a dummy handler that does nothing:
app.action('button', ({ ack }) => ack());
If you're using @slack/interactive-messages, then you can do something similar:
slackInteractions.action({ actionId: 'button' }, () => { return; });
The feedback here is valuable though. I'm exploring what it would take for us to change this behavior within the platform in the future.
If this answers your question, please close the issue.
Thanks @aoberoi! This answers my question and it looks like sending a dummy response will solve our problem.
This is quiet annoying to have to setup a response handler just to be able to display a link button.
Would be great if you we could have a setting to not have slack trying to send a request to the action URL.
+1 @GoMino's point here and then follow up question:
@aoberoi Where does it send the payload if Interactivity is toggled to off on the https://api.slack.com/apps/{YOUR_APP_ID}/interactive-messages page? If "Interactivity" is toggled off, one would expect that no payload should be fired and therefore no error.
This doesn't seem like an error/warning if the app settings has Interactivity disabled, and particularly URL buttons for the most is just a nice looking link button, no need for interactivity on that. Can this be amended on Slack's side? Alternative can also be an option either on the button object to disable payload being fired for that button. Thanks, appreciate your time and work!
I have a use case where the system making the API call is a desktop application and can't implement inbound webhooks (proprietary line of business software.) I would welcome a way to disable the callback/handler behavior (or a "simple button link" block action)
@aoberoi I'm in the same boat here as @plabbett. I have no way to send back a webhook. I'm using the @slack/web-api via postMessage and sending a button element. Are there any other work arounds that can disregard the acknowledgement response without having to incorporate @slack/interactive-messages ?
@joshuatobin no work around at this time 馃槥
I was able to sort of work around this by turning on interactivity and setting the URL to a webhook that returns an empty JSON array and HTTP 200 status code for any request/method sent to it.
Does the trick until I need to handle more interactivity events in the future. It would be nice that if you have interactivity turned off, that the webhook would not be required/fired.
Wanted to raise a flag on hitting this as well. We're using @slack/web-api in a GitHub Action and we're using the button link to send people to URLs created via the Action (which are unique per branch), so there's not really a server to "respond" to the webhook in our case! Would be great to be able to tell the API we don't need it or disable interactivity.
Any reason this is closed? This is definitely not working as intended given if you have interactive turned off it shouldn't expect a return response given no payload is sent
@matoszz this is still the intended behavior from Slack's backend.
So what is the purpose of having interactivity on or off at all if it doesn't change the behavior?
Yes, vote on this. Slack should give an option to disable this.
Most helpful comment
This is quiet annoying to have to setup a response handler just to be able to display a link button.
Would be great if you we could have a setting to not have slack trying to send a request to the action URL.