How to manage conflicting dev environments when building slack slash commands?

user_167810 0
Viewed 226

I have a team of 3-4 people contributing to a slack app (built with Bolt) using slash commands. The app basically boils down to the following:

from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler

# Get SLACK_APP_TOKEN and SLACK_BOT_TOKEN

app = App(token=SLACK_BOT_TOKEN)

@app.command("/the-bot")
def the_bot_slash_command(ack, body, client, respond):
    ack()

    if body["text"] == "foo":
        do_foo()
    else:
        respond("HELP TEXT HERE")

slack = SocketModeHandler(app, SLACK_APP_TOKEN)

We have a free slack workspace to test in, and each dev has set up their own version of the app. The problem is that now we have 3-4 people each running a different bot but with the same slash command. and according to the docs:

Multiple commands may occupy the same name. If it happens and a user tries to invoke the command, Slack will always invoke the one that was installed most recently.

So: is there a correct "The Slack Way" structure to allow individual devs to do dev work on the same slash command?

Obviously I don't want to just have devs running a unique command that they just have to remember not to accidentally commit. The best I've got so far is making @app.command("/the-bot") something more like @app.command(SLASH_COMMAND) and pulling SLASH_COMMAND out of an env variable, allowing individual devs to set their personal test slash command?

slack-api
1 Answers

Unfortunately not. The best option you have is to all set up your own workspaces, or use different slash commands in your staging applications. It's a pain that Slack doesn't make this available via an environment variable in your app, so all this needs to be configured on the api.slack.com site.

A way of doing this might be to request a free testing enterprise grid instance, and then set up numbered workspaces inside of it. This might also help you understand problems with your app that would only occur in an enterprise context, should you want to develop there in the future.

Another, significantly more hacky way, of handling this might be to create a forwarding application that listens for invocations of the slash command, and then forwards the event to the correct staging environment based on some characteristic of the message (eg. what channel it is invoked in).

user_37079400
Related