Warning icon next to button after click

[amkoehler]

Description

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.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements (place an x in each of the [ ])

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

---

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Packages:

Select all that apply:

• @slack/web-api
• @slack/events-api
• @slack/interactive-messages
• @slack/rtm-api
• @slack/webhooks
• I don't know

Reproducible in:

package version: 5.1.0

node version: 10.14.2

OS version(s): Windows 10, macOS

Steps to reproduce:

1. Use sample postMessage payload above
2. Click the 'View Report' button in the message sent to the slack client

Expected result:

A warning icon does not display when clicking a button with a URL

Actual result:

A warning icon displays when clicking a button with a URL

Attachments:

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:

[aoberoi]

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.

[amkoehler]

Thanks @aoberoi! This answers my question and it looks like sending a dummy response will solve our problem.

[GoMino]

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.

[zxlin]

+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!

[plabbett]

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)

[joshuatobin]

@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 ?

[stevengill]

@joshuatobin no work around at this time 😞

[plabbett]

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.

[rdmurphy]

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.

[matoszz]

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

[stevengill]

@matoszz this is still the intended behavior from Slack's backend.

[matoszz]

So what is the purpose of having interactivity on or off at all if it doesn't change the behavior?

[GeniusWiki]

Yes, vote on this. Slack should give an option to disable this.

[hegelstad]

Slack why are you like this

[zxlin]

I imagine that this being closed means that no one is actively paying attention to this.

@seratch any possibility to give this some love? #869 (comment) has quite a few upvotes

[amkoehler]

Reopening. We were able to work around it, but the requested feature in #869 (comment) would be useful.

[shaydewael]

I wanted to drop a note to say that I escalated this issue through our product team letting them know the number of developers that have agreed with #869 . Apologies that this is the current (and frustrating) behavior—I agree it's unintuitive and limits the contexts in which URL buttons can be used without causing end-user confusion.

Unfortunately they've told me that it isn't likely to be worked on in the near future 😞 I understand it's a widespread concern so I'll continue to internally advocate for the change in the capacity I can. I know this isn't helpful for the time being, but I'll be sure to update this issue when the behavior changes.

For use cases when URL buttons are in home tabs or modals, we released a dispatch_action flag in October that allows you to limit the events sent to your app but only in input blocks. However, I know that most of the time buttons will be used in messages or outside of input blocks, so that solution is only applicable to a small subset of scenarios. The eventual solution to this issue will likely be similar (or the same) as this dispatch_action flag, but within messages and non-input blocks.

With that said, I'm going to go ahead and close this issue.

Again, apologies that this is the current-day behavior but unfortunately there really isn't anything I can think of to address this within our SDK since we can't limit the events needing a response that are sent by Slack. I've documented the use cases in this issue, and am happy to relay any additional concerns, but the most direct path to the team that works on the API events will be using the /feedback slash command or emailing feedback@slack.com which will go through our developer support.

[hegelstad]

This also happens when using the web api. I have created a nice notification using Block Kit which is sent by calling POST chat.postMessage from integromat.

…

On 10 Mar 2021, at 01:48, Shay DeWael ***@***.***> wrote:  I wanted to drop a note to say that I escalated this issue through our product team, letting them know how many developers have agreed with #869 . Apologies that this is the current (and frustrating) behavior—I agree it's unintuitive and limits the contexts in which URL buttons can be used without causing end-user confusion. Unfortunately they've told me that it isn't likely to be worked on in the near future 😞 I understand it's a widespread concern so I'll continue to internally advocate for the change in the capacity I can. I know this isn't helpful for the time being, but I'll be sure to update this issue when the behavior changes. For use cases when URL buttons are in home tabs or modals, we released a dispatch_action flag in October that allows you to limit the events sent to your app but only in input blocks which don't work in messages. However, I know that most of the time buttons will be used in messages or outside of input blocks, so that solution is only applicable to a small subset of scenarios. The eventual solution to this issue will likely be similar (or the same) as this dispatch_action flag, but within messages and non-input blocks. With that said, I'm going to go ahead and close this issue. Again, apologies that this is the current-day behavior but unfortunately there really isn't anything I can think of to address this within our SDK since we can't limit the events needing a response that are sent by Slack. I've documented the use cases in this ticket, and am happy to relay any additional concerns, but the most direct path to the team that works on the API events will be using the /feedback slash command or emailing ***@***.*** which will go through our developer support. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- _ Empower Our Customers to Drive Value Through Successful Change_

[ndom91]

Yeah this seems like such odd behaviour for anyone trying to use the Slack "button" block as a fancy "link".

How about being able to disable the interactivity behaviour / "post requests on click" in the button config object in the block json.

[mariabohorquez]

CircleCI-Public/slack-orb#188 suggests some workarounds like hitting postman to get an ok back. I also hit this issue when refactoring some old code to use blocks and needed a button for redirecting and nothing more.

[sarabesh]

facing similar issue while use jenkins slack plugin, please reopen this,

[matthewbordas]

Facing issue when building a slack app as well for our logs. It makes it look like something's wrong which is bad. Would love a fix!

[grahamplace]

+1 on the "I want to use buttons as fancy links" use case, looks like I'll be going back to regular old links in the meantime as the warning icon would be too confusing for users.

Would be great if there were support for non-interactive link-like buttons!

[maldimirov]

As a temp workaround you can use a public service that always returns 200. E.g. I found this service https://httpstat.us/200 that's useful for local testing.

[GeorgeXCV]

People keep mentioning adding callbacks but aren't sharing examples with the webhook, is this not possible? Can I not just add something to avoid this in my one webhook function?

const functions = require('firebase-functions');
const axios = require('axios');

function postToSlack(colour, title, details, resultsURL) {
  return axios.post(
    functions.config().slack.webhook_url,
    {
      attachments: [
        {
          color: colour,
          blocks: [
            {
              type: 'section',
              text: {
                type: 'mrkdwn',
                text: title
              }
            },
            {
              type: 'divider'
            },
            {
              type: 'section',
              text: {
                type: 'mrkdwn',
                text: details
              }
            },
            {
              type: 'actions',
              elements: [
                {
                  type: 'button',
                  text: {
                    type: 'plain_text',
                    text: 'Results'
                  },
                  style: 'primary',
                  url: resultsURL,
                  action_id: 'actionId-0',
                }
              ]
            }
          ]
        }
      ]
    }
  );
}

[nightpool]

Please reconsider this feature, it's very frustrating to have this "requirement" for simple URL buttons

[albertoramires]

Considering this has been an issue for almost four years I doubt we'll see an update but I also support removing this need for a callback. 🙏

[BR00KE]

Consider this another +1 on fixing this issue

[bilbof]

worked around with

post "/slack/interactive-endpoint", to: proc { [200, {}, ['']] }

you need a webserver of course, and a Request URL on your Slack App https://api.slack.com/interactivity/handling

[vin01]

I ran into this as well and found a workaround that seems to work using attachments, here is the json payload:

{
    "text": "New workflow launched",
    "attachments": [
        {
            "text": "`user@server_host`",
            "color": "#3AA3E3",
            "attachment_type": "default",
            "actions": [
                {
                    "url": "https://example.com",
                    "type": "button",
                    "text" : "View workflow"
                },
                {
                    "url": "https://example.com",
                    "type": "button",
                    "text" : "View previous workflow"
                },
            ]
        }
    ]
}