Provide the option to enable multicast for the events api

[drakonstein]

I migrated my RTM bot to use OAuth2 with socket mode and the app worked fine until I had multiple instances listening. With RTM each listener receives the events and can parse them for different tasks. In my use case I have multiple datacenters and an instance of the bot running locally in each one. Each instance listens only for tasks that should be processed in that datacenter and ignores the rest. That works perfectly with RTM, but once I upgraded to OAuth2 with socket mode, only one instance of the bot was receiving the event and it wasn't even usually the one that the message was intended for.

After some investigation I found this [1] section that describes the behavior I was seeing as the intended behavior as well as noting a limitation of 10 connections for the bot token. These limitations weren't listed anywhere else. But that's not really the point. I was hoping we could enable an option for all listeners to be sent the same events rather than a random listener being assigned the event. That would allow me to migrate my app away from RTM, but without that feature I'm going to have to stay on RTM for the time being.

[1] https://api.slack.com/apis/connections/socket-implement#connections

Socket Mode allows your app to maintain up to 10 open WebSocket connections at the same time.

When multiple connections are active, each payload may be sent to any of the connections. It's best not to assume any particular pattern for how payloads will be distributed across multiple open connections.

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

• [ ] slack_bolt.App and/or its core components
• [ ] slack_bolt.async_app.AsyncApp and/or its core components
• [x] Adapters in slack_bolt.adapter
• [ ] Others

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[WilliamBergamin]

Hi @drakonstein thanks for writing in!

Just to make sure I understand correctly:

1. You have multiple instances of bots deploy on different infrastructure
2. These instances all use socket mode + OAuth to connect to slack
3. They all use the same bot credentials to connect to slack
4. You would need all events to be sent to all instances of your bots through socket mode?

[drakonstein]

That sums it up. Each instance listens for different strings/cluster names. @cephbot cluster1 health @cephbot couster2 status, etc. They all authenticate with the same token and only respond when a cluster is mentioned which they are configured for.

We haven't fully scaled/deployed this yet in production. We have about 8 datacenters and each datacenter has 1 to 3 different versions of Ceph which all run in different containers. We're looking at having ~20 actively listening endpoints. The largest I've deployed this so far is ~8 listening endpoints with RTM.

There's a very real possibility that I'll need to restructure things, but firewalls and distances between datacenters would mean having lots and lots of individual bots which could be tricky for end-users to interact with.

Edit- Thinking outside the box I could change the listening mechanism from @cephbot to something just like cephbot which removes the user id being a listening component. Juggling all of the bot users is still less than ideal when the application is identical for all of the instances.

Regardless, this is functionally in the RTM API that can't be duplicated with the Events API.

[WilliamBergamin]

This is a similar issue to #579 and I will have to refer you to this comment as an answer.

This is why I suggested having one dedicated instance that handles user interactivity in the linked comment. If you're going to use only Events API, a slightly simpler way can work. Front-end Socket Mode clients can acknowledge all the events anyways and they can relay the events to all the active backend workers.

Could be a valid long term solution for your event driven architecture, using something such as RabbitMQ, Kafka or any other message broker solution would allow your project to scale easily without limitations

[github-actions[bot]]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[github-actions[bot]]

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.