Custom receiver not respected when when using Socket Mode

[johnboxall]

Description

Hey friends,

I'm working on a Bolt app which uses the Adding Custom HTTP routes feature:

const { App, ExpressReceiver } = require("@slack/bolt")

const receiver = new ExpressReceiver({/* ... */})
receiver.router.get("/", (req, res) => res.send('Hello world'))

const app = new App({receiver, /* ... */})

I'm personally using this feature to serve a OAuth login flow over HTTP that works together with the Slack app to log folks into another service.

Recently, I became aware of Socket Mode, which is helpful in working around having a public webhook in my development environment.

Enabling socketMode in the App quietly discards my custom receiver.

My request is two part-er:

1. 🐛 BUG: It would be great if the App raised an error if you set socketMode and pass a customer receiver if the behaviour is to discard the receiver.
2. ⚡ ENHANCEMENT: I'm not entirely sure how this would work, but I'd like to a) use socketMode and b) add custom HTTP routes

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

• bug
• enhancement (feature request)
• question
• documentation related
• example code 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

Steps to reproduce:

1. Create an App, add a custom receiver with HTTP routes
2. Enable socketMode on your app
3. Navigate to your HTTP routes

Expected result:

The custom HTTP routes are accessible.

Actual result:

The custom HTTP routes are NOT accessible.

---

ps. Bolt was very straight forward to get started with and socketMode seems quite innovative and awesome! Thanks for your hard work on this. ❤️ ❤️ ❤️

[mwbrooks]

Hey @johnboxall, it's good to hear from you 👋🏻

This is a use-case that we overlooked while designing the first release of socketMode, but it's an important one. I think your suggestions of an improvement for the current experience along with an enhancement to support custom routes with socketMode is a solid start for a discussion!

I believe @stevengill is going to weigh-in on this in a bit, so I'll leave it to him to start the discussion!

[stevengill]

Hey @johnboxall!

Glad to see you are using Bolt!

🐛 BUG: It would be great if the App raised an error if you set socketMode and pass a customer receiver if the behaviour is to discard the receiver.

This is a great idea. SocketMode is a receiver in BoltJS. So you aredefinitelyy trying to use 2 receivers which isn't allowed and we should throw an error for this.

⚡ ENHANCEMENT: I'm not entirely sure how this would work, but I'd like to a) use socketMode and b) add custom HTTP routes

This isn't possible today. In SocketModeReceiver, we do use the http module to create routes if you want to support OAuth. See https://github.com/slackapi/bolt-js/blob/main/src/receivers/SocketModeReceiver.ts#L97-L134. But this doesn't have support for custom routes. We have discussed adding support for custom routes in HTTPReceiver (the default receiver since bolt@3.0.0). I imagine that would be when we investigate sharing that code with SocketModeReceiver.

[lranches-sfdo]

@stevengill We at Salesforce are also seeing this limitation as well. I think this would be a great feature as it would be nice to use socket mode to develop locally and handle custom express routes as it's a requirement for my use case. Was pointed to search this repo as this was a question a brought up during an internal Slack session with Bear Douglas.

What would be the alternative? Would we have to use the node slack sdk directly (@slack/socket-mode, @slack/web-api, @slack/events-api) and set up express manually?

[stevengill]

Hey @lranches-sfdo,

Yeah I definitely see the value in custom routes. Especially for this usecase of using socketMode for development but still support some custom routes. I've created an issue to specifically track this issue over at #866

An alternative would be to use those libraries, but it is a good amount of work to setup. Also @slack/events-api has been deprecated in favor of Bolt.

[Mogadampalli-Jayanth]

I am having another common usecase i.e, custom routes in app will be used for health checks in load balancer.But Socketmode doesn't support this right now.
Please provide solution

[majidmade]

Hi friends,

I have a use case that's likely very similar to others' -- I want to use socket mode, but need to expose some custom routes (/version, /health, /metrics) for various operational reasons.

This worked for me; sharing here in case it helps someone else.
(Honestly, I'm a little surprised this worked, so YMMV.)

Create receiver:

const receiver = new ExpressReceiver({
  signingSecret: process.env.SLACK_SIGNING_SECRET
});

Create app:

const app = new App({
  token: process.env.SLACK_BOT_TOKEN,
  signingSecret: process.env.SLACK_SIGNING_SECRET,
  socketMode: true,
  appToken: process.env.SLACK_APP_TOKEN
});

Note that I did not pass the receiver into the app.

Now just start them independently:

await app.start(PORT);
await receiver.start(PORT);

¯\(ツ)/¯

This feels hacky, so I'm still +1'ing the original issue. In the interim, though, hope this is useful to someone!

[seratch]

Thanks again for sharing the feedback here! So, going back to the original topic in this issue:

My request is two part-er:
🐛 BUG: It would be great if the App raised an error if you set socketMode and pass a customer receiver if the behaviour is to discard the receiver.

I just created a new ticket for this task: #1068 We'll track the progress of this task there instead.

⚡ ENHANCEMENT: I'm not entirely sure how this would work, but I'd like to a) use socketMode and b) add custom HTTP routes

We have a ticket issue #866 resolving this. @misscoded will be working on this soon.

[misscoded]

Support for custom HTTP routes has been introduced and will be available with the release of 3.7.0. 🙂

With #1068 and #866 now both resolved, we're going to close this issue. Thank you to all those that participated, from upvoting to providing details around use cases! 🙏🏼