How to run multiple instances of a single slack app with different event subscriptions and receive all events?

[Mogadampalli-Jayanth]

I want to use a single slack app for multiple purposes in Socket mode by running two instances.
and, I have created two App level tokens in slack settings which will be used for each instance.

Now, I have app.message() listener only in one instance.
Other instance is not registered to message listener and it only retrives msg using conversation.history api.

Now when I run two instances at a time and if I post a message in slack channel then only instance which has message listener event should receive the event generally.
But the instance which has message listener is not receiving all message events.

Can you please explain the reason for this case?
Also please tell whether two instances with different event subscriptions using different app tokens in socket mode can work?

[seratch]

Hi @Mogadampalli-Jayanth, thanks for writing in.

When you run multiple Socket Mode client processes, the Slack server-side sends payloads to any of the active connections in a round-robin manner. Using two app-level tokens does not make any difference. If you do tests with more events, you will observe the message events can be delivered to another instance (if not, probably the other instance is not properly connected).

Also please tell whether two instances with different event subscriptions using different app tokens in socket mode can work?

For the reason that I mentioned above, this is not possible with one Slack app configuration. If you need a different event subscription for some reason, the only way is to create a different app for it.

I hope this helps.

[WarpRat]

Sorry to necro an old issue but I've been trying to find documentation on the behavior with multiple clients in socket mode and came across this. Is there somewhere in the docs where this is defined in more detail? We just want to have multiple replicas for high availability during cluster events.

[BMonsalvatge]

Also interested in the above. Wondering where this is sourced in the docs, or maybe it should be more clear / a best practices in production guide.

[moertel]

A double sorry from my side to necro this old issue once again but I found a workaround that I can live with and that accomplishes the task well enough for now. Maybe it's useful for some of you.

The lucky circumstances in my case are these:

• I own both Slackbot apps and have full control over them
• It's ok to run just 1 instance each

The downsides:

• Displays a misleading error message on the UI 50% of the time
• Requires both bots to be coupled and be self-aware
• Response delay of about 3 seconds

The key is to have listener-parity between both Slackbots, and to not ack() the request if it should be handled by the other one. When one instance for each bot is deployed, there's a 50/50 chance it will land on the right one the first time. If it hits the wrong one, do not ack() the message! This will display an error on the frontend but the message will be forwarded to the other connected instance eventually which is then definitely the right one.

[nsantiag]

I'm creating 2 apps hoping each could handle different events (one handles messages and the other, home events). Looking at @moertel 's comment is not a good UX and I hope Slack fixes this. What's the sense of having multiple app tokens if they're required to listen to same set of events?