New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate responses to commands after bot is left idling w/ celluloid #236
Comments
Without debugging I am going to guess that it's reconnecting, and re-registering commands when that happens. I'll take a look when I get a chance. |
yeah seems to be that way, i would love to have an option/ENV to disable reconnect et-all and just throw a exception and die! in our case the cluster would take care of the bot and recreate it anyway 👍 |
if you can lead me to the file/place where the reconnect happens, i am happy to contribute such a change! |
Reconnect happens in slack-ruby-client with a ping worker. There's a lot of detail in https://code.dblock.org/2019/03/04/solving-slack-side-disconnects-in-slack-ruby-client.html with links. But I think the problem here is simpler and is something about the reconnect semantics changing over the last few versions of the client. I would add a bunch of logs to see what's being reloaded and when. |
changing to |
Were you using celluloid before or faye-websocket? |
default, i think it was celluloid |
We're happy to report that after a week of testing using async-websocket and |
I would appreciate if someone could get to the bottom of this with celluloid. Good project to dive deep! |
+1! Have also been experiencing this behavior after switching to celluloid-io. If I have uninstalled |
If your Gemfile has async-websocket you're all good. The ENV setting is to run tests in this project. |
That earlier fix didn't work lol. But I did find an issue on the slack-ruby-bot github repo that seems to describe the exact issue im having [here](slack-ruby/slack-ruby-bot#236). TL;DR it seems like celluloid-io is causing duplicate reconnect calls to happen. I do recall switching to celluloid-io from async-websocket a while back during the big refactor, so it seems likely that this could be cause. The reason I switched was due to a conflict between action-cable and ruby-slack-bot via async-websocket mismatch versions. **Looks as though I need to update to rails 6 to get a newer version of action-cable that is more lenient with its dependency on **
We've left our bot alone this weekend, and when coming back to work this monday, it starts replying 12 times for the same question 😱. Will try the async-websocket trick. |
@dblock thanks! Though I had to upgrade to Rails 6 because of a version conflict with, switching back to using |
I wish someone actually fixed the celluloid bug. Or maybe someone can do the work to deprecate celluloid usage everywhere and hardcode async-websocket? |
We're having an issue where the bot once idle for a while will process commands multiple times. My research lead me to the issue in Slack-ruby-bot which I included below. See: slack-ruby/slack-ruby-bot#236
Use async-websocket instead of celluloid: See slack-ruby/slack-ruby-bot#236
Hi there,
We are using this gem in a simple project that uses a database. We've noticed that when we let the app idle for some time (unsure exactly for how long, maybe about an hour) then the bot processes text commands multiple times. The gems
slack-ruby-bot
andslack-ruby-client
are on the latest version.I have created a minimal setup with which I am able to reproduce this issue: https://github.com/jillguyonnet/slack_ruby_bot_minimal. This is a very simple app that manages a list of items. Note that it was based on https://github.com/slack-ruby/slack-ruby-bot/blob/master/TUTORIAL.md and uses the MVC approach. The available commands are:
hi
show
: print a list of itemsadd
: add an item to the listclear
: clear the listSimilar to our real project, the issue of multiple command processing happens when I let the app run for a while. Here is a screenshot where the bot responds twice to
hi
:The steps to reproduce are:
We are currently investigating potential sources for this issue. Without confirmation, we think these might include:
websocket_ping
setting on the realtime client (https://github.com/slack-ruby/slack-ruby-client/blob/master/README.md#configuring-slackrealtimeclient) currently not set to zero. Could this issue be caused by the client attempting to reestablish its connection to the message server?CONCURRENCY
environment variable is not set.Would you, based on this information, be able to suggest the cause of this issue and the best way to fix it?
Thanks
The text was updated successfully, but these errors were encountered: