Throws a Runtime Error if team is already regstered. about slack-ruby-bot-server HOT 6 OPEN

I think you could just implement the re-install workflow and succeed in that case instead of raising an error?

from slack-ruby-bot-server.

I've to re implement the whole teams_endpoint or have to maintain two redirect URLs? Not sure if it is ideal, I am wondering what that exception's purpose is? Because we would want new tokens to be updated in Teams model in case user re-installs?
Sorry if that doesn't make sense, new to Slack bot Dev.

from slack-ruby-bot-server.

@amar-sharma

You definitely don't want to reimplement the endpoint and maintain 2 URLs, just get rid of the exception. But you can't remove it, its original intent is to avoid calling activate! which in RTM starts a new instance of a bot. If you do that, you'll end up with 2 connections both responding, which is ... bad. For RTM implementations you'd need to find a way to shutdown the existing connection, and start a new one, which is non-trivial, or raise as we do now but elsewhere. For event-based bots this is no longer useful because there's no "start" of any kind of worker and you could theoretically call activate! as many times as you want because it does nothing.

All of this needs to be tested and confirmed.

from slack-ruby-bot-server.

So the activate is only used for RTM, If I am not using RTM I can just get rid of activate! all together?
How about team.deactivate id if team.active? instead of raise and let it proceed?

from slack-ruby-bot-server.

In your own code I think it's safe to just remove both the exception and activate!, but I would double-check. You should try and make this work in a PR here though or you'll have a hard time tracking this in the future since it's sort of an interface.

from slack-ruby-bot-server.

okay thank you for the response, I'll look into the code, find a way to reopen the connection and create a PR.

from slack-ruby-bot-server.