Q: Long-running operation is blocking message? about slack-ruby-bot HOT 6 OPEN

I think this is because the buffer for the web socket is flushed later. I see two options:

EM.next_tick do
 client.say ...
end

Or EM.defer for a long running thing.

Or use a web client, client.web_client.chat_postMessage(channel: ..., text: ...) which will use the web API to post immmediately.

Generally I think you don't want to block, so I think wrapping the long operation in EM.defer is probably the best solution.

Le us know which one works best?

from slack-ruby-bot.

I've also noticed that while doing said long running operation that the bot doesn't respond to other requests. So I've taken to running the blocks for any commands that take a while in a new thread. This allows the bot to answer other questions at the same time. One thing to note, that will break test cases as the test case doesn't know to wait for the detached thread. To solve this I enclose the block in a lambda and then check if the environment is test, if so execute the block without the thread, otherwise pass the block to the thread to be run.

from slack-ruby-bot.

I noticed this is the behavior with faye-websocket but if you use celluloid-io gem then you get one message, then the pause while it works, then the next response.

from slack-ruby-bot.

I found that using Celluloid.defer seems to work for allowing the bot to respond to other commands while processing a long-running command. It also allows me to use client.say in the deferred block. Maybe this (or something similar) should become a standard feature in how SlackRubyBot responds to commands?

from slack-ruby-bot.

I am down with a global option to defer execution of all commands, including regex parsing. Would love a PR, please!

from slack-ruby-bot.

I suppose it would then need to be something that works w/ both Celluloid and EventMachine. Possibly not too much code to implement but would certainly require major changes to the specs.

from slack-ruby-bot.