litaio / lita-slack Goto Github PK

View Code? Open in Web Editor NEW

141.0 141.0 136.0 214 KB

A Slack adapter for Lita.

License: MIT License

Ruby 100.00%

chatops lita lita-adapter ruby slack slack-bot

lita-slack's People

Contributors

Stargazers

Watchers

Forkers

marceldegraaf milo-ft zackola hubb mikian josacar edwardloveall benodom bandito ramarnat chendo tokada sudden-break byroot stevenharman terenced envoy freibuis ushkinaz hickey zheei kevinbond erikogan suncoast-devs clintkelly jaisonerick scpr reidblomquist t33chong ajaleelp nulogy onetwotrip directionless code4days cloudxtreme visioncritical tehp boone jamesdabbs ericboehs amalagaura flicken jkeiser rposborne orejosh gbradleymitchell rossgeesman robdiciuccio ekilah ousamg 17hats christhomson edgarortegaramirez onewheelskyward maxvt aar0ntw brentm5 dmann samuelmartini ramanan12345 radioberry noir-neo ryanvz surajreddy miry maeken2010 flexera-public powerdms spajus shopify twister915 alexanderpavlenko edymerchk jacobbullock dennis kansaz mdarveau elliott-davis persado vrtdev 247sports ahaymond firstleads zymblog clustermarket varu3 firehydrant yuenmichelle1 fabiokr stangc paktor civio zeuikli clinicalplatform blackbellme tnak-thrive zooniverse hachimitsu890 ifttt krororo

lita-slack's Issues

Name and mention name should be set automatically

Name ("real name" in Slack) and mention name ("username" in Slack) should be automatically assigned with the values in the Slack integration config when the bot connects.

Support slash commands

Can we support slack slash commands?

Slash commands in Slack has some benefits over the way we are doing today:

They work everywhere (PVT, channels, private channels, etc)
They provide documentation integrated into the interface

SlackBotsy looks like support this type of integration:

https://github.com/rlister/slackbotsy/blob/master/lib/slackbotsy/bot.rb#L134

invalid byte sequence in US-ASCII (ArgumentError)

Seeing lita-slack crash frequently, as follows:

/usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/message_handler.rb:102:in `gsub': invalid byte sequence in US-ASCII (ArgumentError)
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/message_handler.rb:102:in `remove_formatting'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/message_handler.rb:43:in `body'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/message_handler.rb:115:in `dispatch_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/message_handler.rb:158:in `handle_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/message_handler.rb:17:in `handle'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/rtm_connection.rb:99:in `block in receive_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.5.0/lib/lita/adapters/slack/event_loop.rb:9:in `block in defer'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.7/lib/eventmachine.rb:1054:in `call'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.7/lib/eventmachine.rb:1054:in `block in spawn_threadpool'

I am trying to set up our lita bot and any time I am using the Slack adapter DNS resolution fails. This obviously makes writing plugins for my environment near impossible. The same DNS calls in the Shell adapter work perfectly. You can re-create this by just firing up a lita instance connected to slack and do any sort of operation that would require a dns resolution to complete. Easiest way to test is is install lita-dig and use that. It will fail every time if it's connected to the slack adapter, at least it has for me :(

incoming webhooks not being caught

I have messages coming into a channel through an incoming webhook that lita-slack can't intercept. It would be nice to have an event fire when it notices an incoming webhook.

In the response object, room and and room id are the same

When sending messages in a private conversation, or in a private group named 'hubot-testing', the handler always reports the room.name to be the ID of the room. For some of the functionality I'm building, I need the human readable name of the room. How can I obtain this value?

Feature request: Channel whitelist

By default, anyone can invite Lita into any Slack channel. In certain environments this may be undesirable. For example, one might want to extend Lita to perform dangerous operations and the people who can tell her to do those things should be restricted. While one can use Lita's authorization groups feature to implement this, it is sometimes easier to keep her open but only accessible via a restricted channel.

Make it possible to specify a Slack channel whitelist for Lita. If specified, and Lita is invited to a channel in which she doesn't belong, optionally say something, and leave immediately.

Feature Request: Interactive Buttons

How do you think about supporting https://api.slack.com/docs/message-buttons

Watch for user to come online

I'm working on a handler that requires knowing (or subscribing to) a user's online/offline status.

I want to send my bot to send a message to a user once they come online (rather than send it immediately if they are offline). Does the Slack API expose any event like that?

set_topic not working

hello,

I tried to use robot.set_topic(response, 'some topic') in my lita handler.
it seems that this method doesn't pass the room's id to the slack api but a string representation of the room object, so it misses room.id somewhere in the chain.

then I tried to use set_topic directly via robot.chat_service.api.set_topic(response.room.id, 'some topic') but still no luck. I always get channel_not_found error from slack. I checked the call made and it looks good to me (https://api.slack.com/methods/channels.setTopic).
could it be that lita-slack somehow computes the wrong room id? there could be also something wrong with the api call to slack?

Capability to add a reaction to a message

Slack's API supports adding an emoji response to a message: https://api.slack.com/methods/reactions.add

I'd like this capability so that a user knows that Lita's heard them, and is processing the message, as I have a task that runs 2–5 network calls off the one message, so it can take a while to get a response. (and responding with a ":+1" would send a notification to everyone in the channel).

Lita `mention_name` is not cleaned up when changing Slack username.

When changing your username in Slack, lita-slack will leave your old "mention name" around. At that point you'll have multiple lita.users.metion_name.* entries pointing to your Slack UID. If you then attempt a Lita::User.fuzzy_search for your old mention_name, your Lita::User record will be found. Even though it shouldn't be.

A fix for this might also be related to #33.

handle_unknown event publishing policy wrt presence_changed

#53 refers to a presence_change event, which I'm interested in tracking, as well.

Is there a reason that this block couldn't publish the event anyway? If no handler is subscribed to the event, isn't it close to a no-op?

Might there be a preference for, say, adding handle_presence_change to this block?

<@UNIQUEID> translation uses user full name, rather than their mention name

A user mention of the form <@uniqueid> is translated to @#{user.name}, which is the user’s full name. So @erik would be passed to Lita handlers as @Erik Ogan.

This is particularly problematic for lita-karma, where @erik++ is translated to @Erik Ogan++, changing the term being incremented (to “Ogan”). I do not believe this is what most users would expect.

Lita::Room's name is not correct

When inspecting a room_object from a response in a handler, the name it display's there is a copy of the ID (using lita-slack adapter).

I believe that this adapter is missing a call to https://api.slack.com/methods/channels.info to fill the correct channel name.

lack of debug output

I am having issues getting this plugin to work and setting the log level to debug is not displaying any information at all

[2015-05-12 13:41:33 UTC] WARN: Lita::Handler.default_config is deprecated and will be removed in Lita 5.0. Use Lita::Handler.config instead. The method was found defined in the jenkins handler.
[2015-05-12 13:46:22 UTC] DEBUG: Connecting to the Slack Real Time Messaging API.
[2015-05-12 13:46:24 UTC] INFO: Disconnected from Slack.
[2015-05-12 13:46:24 UTC] DEBUG: Closing connection to the Slack Real Time Messaging API.

lita wont stay connected to slack and I have no way of knowing why.

Cannot send message on connected event

I am using the lastest version of lita slack 1.4.0 and the following code does not work in my handler. Works fine with a shell adapter.. Nothing crashes. I see the send_messages call into the send_messages of the slack adapter . Then the Event.defer. but nothing every come to slack (maybe an issue with websocket?)

module Lita
  module Handlers
    class MyHandler < Handler
    on :connected, :lunch_notifier

   def lunch_notifier(payload)
        p :lunch_notifier
        target = Source.new(room: '#general')
        robot.send_messages(target, ['test'])
  end
end
end

How do you populate `config.robot.admins` for this handler?

I'm trying to assign admins for our slack bot but I can't figure out what's required in that admins array. Is it the user's name? Their slack id? After some digging I did find this tool at slack to retrieve that info but I'm having a hard time getting the group add/delete functionality to work - https://api.slack.com/methods/users.list/test

I've added our user id's to the config, restarted the bot, and when I run <bot name> auth add <my name> test_group it does nothing.

Any pointers?

Can't provide user as target for send_messages

robot.send_message(user, "This should be a private message.")

fails, where user is response.user.

According to the Lita API, this should work: http://www.rubydoc.info/gems/lita/Lita/Robot#send_messages-instance_method

The error it fails with is:

ERROR:  crashed. The exception was:
undefined method `private_message?' for #<Lita::User:0x00562d8bf1abd0>
Full backtrace:
/usr/local/bundle/gems/lita-slack-1.7.2/lib/lita/adapters/slack.rb:50:in `channel_for'
/usr/local/bundle/gems/lita-slack-1.7.2/lib/lita/adapters/slack.rb:29:in `send_messages'
/usr/local/bundle/gems/lita-4.6.1/lib/lita/robot.rb:129:in `send_messages'

I tried to work around it by using Room.find_by_id(user.id) instead, but I received the same error.

URL handling not working with lita templating functionality

Hello,

I'm trying out the lita templating functionality using the slack adapter but can't seem to get the URL handling to work.
I'm using the following code in my .erb file:

*GitHub Org Pull Requests:*
<% @github_open_issues.each do |repo_name, issues| %>
<% issues.each do |issue| %>
• <%= repo_name %>: <<%= issue.html_url %>|pull request #<%= issue.number %>> - <%= issue.title %> - by <<%= issue.user.html_url %>|<%= issue.user.login %>>
<% end %>
<% end %>

The output now is:

• puppet-alternatives: <https://github.com/cegeka/puppet-alternatives/pull/1|pull request #1> - fix: insync function comparing current and should items - by <https://github.com/vladnazarenko|vladnazarenko>

But I would like to see the following:

• puppet-alternatives: pull request #1 - fix: insync function comparing current and should items - by vladnazarenko

Any suggestions on what I'm doing wrong ?
I think I'm using the correct syntax for links in Slack but any help would be appreciated..

Lita stops if Slack closes websocket

We've been having this problem for few months. Occasionally lita would simply 'crash' and stop working with no stacktrace.

I've traced it down to this:
https://github.com/kenjij/lita-slack/blob/master/lib/lita/adapters/slack/rtm_connection.rb#L48

It looks like when websocket gets closed upstream by Slack, the whole Eventloop gets stopped instead of retry.

Is this intended behaviour? Shouldn't connection be reopened?

No errors, but bot isn't joining channels or responding.

I have the following in my config:

config.robot.name = "uncle_ho"
config.robot.adapter = :slack
config.adapters.slack.token = "XXX"

And in slack I have a Lita bot with the username uncle_ho.

Running lita start or lita & doesn't give me any errors. But, it doesn't seem to do anything. I get the prompt when I'm not running it as a background process. But, that's it.

I don't have any robot admins set. Not sure what that is supposed to be for. Also, not sure who's ID I'm supposed to put in there...mine or the bot's. Regardless, I have no idea where to find those IDs.

Feature Request: Undo Effects of Slack's URL Autolinking Before Passing Input Downstream?

Hello,

I have previously conversed a little with the support team at Slack about this issue, @paulhammond included.

Essentially, the issue is that Slack rewrites domain names and FQHNs as clickable URLs, essentially rewriting a user's input of "apple.com" to (I believe) <http://apple.com|apple.com>, which is obviously handy most of the time within Slack, but in regards to Lita, it breaks several plugins. Two examples are lita-whois and lita-dig.

Paul indicated that the hubot adapter recently addressed this (slackapi/hubot-slack#109), and that he would be amenable to chiming in here in regards to a discussion on how best to approach this in lita-slack.

lita-slack not capable with Lita master

At Shopify, we love new features from Lita master and try to stay on the upstream.
But with the last upstream update, we found that lita-slack stopped working.

Unfortunately there is no stacktrace in the Lita log. Here is all we've got:

2016-03-01_09:33:51.77846 Outbound message failed: NoMethodError: undefined method `im_for' for nil:NilClass

@jimmycuadra

Why are links filtered out?

Why are links filtered out when chatting with slack?

eg. http://www.example.com/|example.com according to the Slack Messaging API should output a friendly link. However these links are specifically filtered out as per:

https://github.com/kenjij/lita-slack/blob/v1.6.0/lib/lita/adapters/slack/message_handler.rb#L55
https://github.com/kenjij/lita-slack/blob/v1.6.0/spec/lita/adapters/slack/message_handler_spec.rb#L344

Reply messages are not ordered

I have the following code in custom handler.

response.reply("First message")
response.reply("Second message")

and in Slack most of the times I see

Second message
First message

Is this a problem with the Slack integration or Lita in general?

undefined method `token=`

Lita Version 4.0.1

I have the gem "lita-slack" in my Lita dir's gemfile, and I have the config set to use the example you have in the README

config.robot.adapter = :slack
config.adapters.slack.token = "REDACTED"```

But i'm getting this error
vagrant@lita-dev:/vagrant$ lita start [2014-12-12 21:34:06 UTC] FATAL: Lita configuration file could not be processed. The exception was: undefined method token=' for nil:NilClass
Full backtrace:
/vagrant/lita_config.rb:21:in block in <top (required)>' /usr/local/lib/ruby/gems/2.1.0/gems/lita-4.0.1/lib/lita/registry.rb:17:in configure'
/vagrant/lita_config.rb:1:in <top (required)>' /usr/local/lib/ruby/gems/2.1.0/gems/lita-4.0.1/lib/lita/configuration_builder.rb:49:in load'
/usr/local/lib/ruby/gems/2.1.0/gems/lita-4.0.1/lib/lita/configuration_builder.rb:49:in load_user_config' /usr/local/lib/ruby/gems/2.1.0/gems/lita-4.0.1/lib/lita.rb:71:in run'
/usr/local/lib/ruby/gems/2.1.0/gems/lita-4.0.1/lib/lita/cli.rb:77:in start' /usr/local/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:in run'
/usr/local/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in invoke_command' /usr/local/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:in dispatch'
/usr/local/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in start' /usr/local/lib/ruby/gems/2.1.0/gems/lita-4.0.1/bin/lita:6:in <top (required)>'
/usr/local/bin/lita:23:in load' /usr/local/bin/lita:23:in

Type error in ImMapping

2015-01-26_20:07:49.59471 [2015-01-26 20:07:49 UTC] ERROR: Lita::Handlers::Help crashed. The exception was:
2015-01-26_20:07:49.59488 undefined method `im_open' for "xoxb-REDACTED":String
2015-01-26_20:07:49.59502 Full backtrace:
2015-01-26_20:07:49.59515 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/im_mapping.rb:22:in `block in im_for'
2015-01-26_20:07:49.59528 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/im_mapping.rb:21:in `fetch'
2015-01-26_20:07:49.59541 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/im_mapping.rb:21:in `im_for'
2015-01-26_20:07:49.59553 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/rtm_connection.rb:32:in `im_for'
2015-01-26_20:07:49.59562 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack.rb:36:in `channel_for'
2015-01-26_20:07:49.59569 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack.rb:20:in `send_messages'
2015-01-26_20:07:49.59577 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/robot.rb:97:in `send_messages'
2015-01-26_20:07:49.59584 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/message.rb:82:in `reply_privately'
2015-01-26_20:07:49.59593 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/handlers/help.rb:17:in `help'
2015-01-26_20:07:49.59601 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/callback.rb:31:in `public_send'
2015-01-26_20:07:49.59608 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/callback.rb:31:in `call'
2015-01-26_20:07:49.59616 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/handler/chat_router.rb:88:in `dispatch_to_route'
2015-01-26_20:07:49.59623 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/handler/chat_router.rb:73:in `block in dispatch'
2015-01-26_20:07:49.59631 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/handler/chat_router.rb:70:in `map'
2015-01-26_20:07:49.59638 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/handler/chat_router.rb:70:in `dispatch'
2015-01-26_20:07:49.59646 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/robot.rb:58:in `block in receive'
2015-01-26_20:07:49.59655 /usr/lib/ruby/2.2.0/set.rb:283:in `each_key'
2015-01-26_20:07:49.59663 /usr/lib/ruby/2.2.0/set.rb:283:in `each'
2015-01-26_20:07:49.59670 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/robot.rb:55:in `map'
2015-01-26_20:07:49.59679 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/robot.rb:55:in `receive'
2015-01-26_20:07:49.59686 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/message_handler.rb:48:in `dispatch_message'
2015-01-26_20:07:49.59694 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/message_handler.rb:83:in `handle_message'
2015-01-26_20:07:49.59701 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/message_handler.rb:17:in `handle'
2015-01-26_20:07:49.59709 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/rtm_connection.rb:88:in `receive_message'
2015-01-26_20:07:49.59716 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/rtm_connection.rb:41:in `block (2 levels) in run'
2015-01-26_20:07:49.59724 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:31:in `call'
2015-01-26_20:07:49.59731 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:31:in `block in emit'
2015-01-26_20:07:49.59739 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:30:in `each'
2015-01-26_20:07:49.59747 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:30:in `emit'
2015-01-26_20:07:49.59755 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/faye-websocket-0.9.2/lib/faye/websocket/api/event_target.rb:44:in `dispatch_event'
2015-01-26_20:07:49.59762 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/faye-websocket-0.9.2/lib/faye/websocket/api.rb:95:in `receive_message'
2015-01-26_20:07:49.59770 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/faye-websocket-0.9.2/lib/faye/websocket/api.rb:38:in `block in initialize'
2015-01-26_20:07:49.59777 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:31:in `call'
2015-01-26_20:07:49.59785 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:31:in `block in emit'
2015-01-26_20:07:49.59792 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:30:in `each'
2015-01-26_20:07:49.59800 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/event_emitter.rb:30:in `emit'
2015-01-26_20:07:49.59810 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/hybi.rb:396:in `emit_message'
2015-01-26_20:07:49.59818 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/hybi.rb:379:in `emit_frame'
2015-01-26_20:07:49.59826 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/hybi.rb:118:in `parse'
2015-01-26_20:07:49.59833 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/websocket-driver-0.5.1/lib/websocket/driver/client.rb:56:in `parse'
2015-01-26_20:07:49.59841 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/faye-websocket-0.9.2/lib/faye/websocket/api.rb:134:in `parse'
2015-01-26_20:07:49.59848 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/faye-websocket-0.9.2/lib/faye/websocket/client.rb:77:in `receive_data'
2015-01-26_20:07:49.59856 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.4/lib/eventmachine.rb:187:in `run_machine'
2015-01-26_20:07:49.59863 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.4/lib/eventmachine.rb:187:in `run'
2015-01-26_20:07:49.59870 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack/rtm_connection.rb:36:in `run'
2015-01-26_20:07:49.59879 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-slack-1.0.4/lib/lita/adapters/slack.rb:14:in `run'
2015-01-26_20:07:49.59888 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/robot.rb:69:in `run'
2015-01-26_20:07:49.59895 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita.rb:79:in `run'
2015-01-26_20:07:49.59903 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/lib/lita/cli.rb:77:in `start'
2015-01-26_20:07:49.59910 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
2015-01-26_20:07:49.59917 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
2015-01-26_20:07:49.59928 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
2015-01-26_20:07:49.59940 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
2015-01-26_20:07:49.59948 /opt/apps/lita/shared/bundle/ruby/2.2.0/gems/lita-4.1.0/bin/lita:6:in `<top (required)>'
2015-01-26_20:07:49.59956 /opt/apps/lita/shared/bundle/ruby/2.2.0/bin/lita:23:in `load'
2015-01-26_20:07:49.59963 /opt/apps/lita/shared/bundle/ruby/2.2.0/bin/lita:23:in `<main>'

Possibility of Monospaced Font Output in Some Contexts

Also,

I don't yet have in mind an elegant approach to this at the lita-slack level, but I raise the question here for possible discussion:

A number of lita plugins (one example is lita-ascii, but it is not the only one) work best when their output is presented in a monospaced font. Obviously, it wouldn't be too difficult for lita-slack to facilitate this by inserting triple ticks at the beginning and end of the output before passing it back to Slack, but the question would be, how does lita-slack know when this would be desired? Again, I'm not yet sure, but raise it here for discussion in regards to a possible enhancement of some sort to lita-slack.

How to get channel ids

In some occasions I want to send a message in a different room from the one that robot was called. What is the proper way to translate the channel/room name into a channel id ?

I know one option would be to make an API request and retrieve the full list of channels, but is there another way?

And then, to DM users, how can I get the corresponding channel id to DM them ?

So far I've just created a lita say channel command that gets the channel id from "response.message.source.room", and then store it in a table for later use. Is there a more direct way?

Thanks

im.open returned an error

Using master as my gem.
No optional configs set.

[2016-03-28 20:45:56 UTC] ERROR: Lita::Handlers::Ai crashed. The exception was:
Slack API call to im.open returned an error: cannot_dm_bot.
Full backtrace:
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/api.rb:99:in `call_api'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/api.rb:24:in `im_open'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/im_mapping.rb:23:in `block in im_for'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/im_mapping.rb:22:in `fetch'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/im_mapping.rb:22:in `im_for'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/rtm_connection.rb:36:in `im_for'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack.rb:65:in `channel_for'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack.rb:43:in `send_messages'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/robot.rb:129:in `send_messages'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-ai-0.1.1/lib/lita/handlers/ai.rb:13:in `chat'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/callback.rb:31:in `public_send'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/callback.rb:31:in `call'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/handler/event_router.rb:61:in `block in trigger'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/handler/event_router.rb:59:in `map'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/handler/event_router.rb:59:in `trigger'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/robot.rb:183:in `block in trigger'
/usr/local/rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/set.rb:283:in `each_key'
/usr/local/rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/set.rb:283:in `each'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/robot.rb:180:in `trigger'
/usr/local/rvm/gems/ruby-2.2.3/gems/lita-4.7.0/lib/lita/robot.rb:72:in `receive'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/message_handler.rb:122:in `dispatch_message'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/message_handler.rb:162:in `handle_message'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/message_handler.rb:18:in `handle'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/rtm_connection.rb:100:in `block in receive_message'
/usr/local/rvm/gems/ruby-2.2.3/bundler/gems/lita-slack-38a968fd88e4/lib/lita/adapters/slack/event_loop.rb:10:in `block in defer'
/usr/local/rvm/gems/ruby-2.2.3/gems/eventmachine-1.2.0.1/lib/eventmachine.rb:1076:in `call'
/usr/local/rvm/gems/ruby-2.2.3/gems/eventmachine-1.2.0.1/lib/eventmachine.rb:1076:in `block in spawn_threadpool'

Works fine if I just use the gem from rubygems.org. Unfortunately the optional parse options weren't available from there so tried out master.

Error during start up in user create in 1.7.1

I'm seeing a problem, that I believe, is while the bot is creating users in Redis using 1.7.1. I'm not seeing this in 1.7.0 so I think it has to do with parsing the metadata for a particular user but I'm not able to determine what data is causing the error.

Here's the full debug output of the startup error, which I'm afraid won't be very useful.

/var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:129:in value': ERR wrong number of arguments for HMSET (Redis::CommandError) from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:121:in_set'
from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:67:in block in finish' from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:66:ineach'
from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:66:in each_with_index' from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:66:ineach'
from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:66:in map' from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/pipeline.rb:66:infinish'
from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:149:in block in call_pipeline' from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:279:inwith_reconnect'
from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis/client.rb:147:in call_pipeline' from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis.rb:2136:inblock in pipelined'
from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis.rb:37:in block in synchronize' from /usr/lib/ruby/2.1.0/monitor.rb:211:inmon_synchronize'
from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis.rb:37:in synchronize' from /var/lib/gems/2.1.0/gems/redis-3.2.1/lib/redis.rb:2132:inpipelined'
from /var/lib/gems/2.1.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:414:in namespaced_block' from /var/lib/gems/2.1.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:266:inpipelined'
from /var/lib/gems/2.1.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:414:in namespaced_block' from /var/lib/gems/2.1.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:266:inpipelined'
from /var/lib/gems/2.1.0/gems/lita-4.6.1/lib/lita/user.rb:109:in save' from /var/lib/gems/2.1.0/gems/lita-4.6.1/lib/lita/user.rb:22:increate'
from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack/user_creator.rb:9:in create_user' from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack/user_creator.rb:22:inblock in create_users'
from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack/user_creator.rb:22:in each' from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack/user_creator.rb:22:increate_users'
from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack/rtm_connection.rb:31:in initialize' from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack/rtm_connection.rb:20:innew'
from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack/rtm_connection.rb:20:in build' from /var/lib/gems/2.1.0/gems/lita-slack-1.7.1/lib/lita/adapters/slack.rb:22:inrun'
from /var/lib/gems/2.1.0/gems/lita-4.6.1/lib/lita/robot.rb:80:in run' from /var/lib/gems/2.1.0/gems/lita-4.6.1/lib/lita.rb:80:inrun'
from /var/lib/gems/2.1.0/gems/lita-4.6.1/lib/lita/cli.rb:77:in start' from /var/lib/gems/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:inrun'
from /var/lib/gems/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in invoke_command' from /var/lib/gems/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:indispatch'
from /var/lib/gems/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in start' from /var/lib/gems/2.1.0/gems/lita-4.6.1/bin/lita:6:in<top (required)>'
from /usr/local/bin/lita:23:in load' from /usr/local/bin/lita:23:in

If there is anything further I can provide to help, please let me know.

Handling large messages

This is a continuation of the conversation at: josacar/lita-jobs#3

At the moment, any messages larger than MAX_MESSAGE_BYTES are dropped, with an exception raised:
https://github.com/kenjij/lita-slack/blob/master/lib/lita/adapters/slack/rtm_connection.rb#L103

It would be preferred in my humble opinion to auto-convert anything larger than MAX_MESSAGE_BYTES to a Slack text attachment. Chunking a message into 1..n pieces could still fill up a Slack room and be undesirable for users in the channel, whereas the Slack text attachment requires users to click-to-expand.

I'd be happy to submit a PR; thanks for your feedback.

Runtime Error: Encryption not available on this event-machine

I'm on CentOS 7,
Now I get following error:

$ lita
[WARNING] MultiJson is using the default adapter (ok_json).We recommend loading a different JSON library to improve performance.
terminate called after throwing an instance of 'std::runtime_error'
what(): Encryption not available on this event-machine
Aborted (core dumped)

I have openssl and openssl-devel installed.

Adapter disconnects after a period of time

lita-slack 1.7.2
lita 4.6.1

In the last couple of days our lita bot has been disconnecting from Slack every couple of minutes. I've also noticed that when it comes back up, it will only respond to one or two commands before it stops responding to anything (yet it's still connected). After about 3-5 minutes it will then just simply disconnect from a close event:

[2015-12-11 16:58:13 UTC] INFO: Closing because of #<Faye::WebSocket::API::CloseEvent:0x00000000be7328>
[2015-12-11 16:58:13 UTC] INFO: Disconnected from Slack.

I've used pry-remote to take a look at that Close Event and it's seems normal. In fact, all that was in the buffer was:

@buffer="\x81A{\"type\":\"presence_change\",\"user\":\"USERID\",\"presence\":\"active\"}\x81\x02{}", @offset=71>,

I've tried disabling all of our plugins, but the same behaviour occurs. My guess is that the lita-slack adapter is being rate-limited, and subsequently terminated, but I couldn't find a response to back that hypothesis up.

I also tried to turn debugging on for the Faye::WebSocket::Client class, but couldn't figure out where to specify it aside from the options hash. And since { debug: true } is not a valid option, lita crashed instantly.

Any help in debugging this issue would much be appreciated! Thanks :)

Random disconnections from Slack

I am seeing my lita bot randomly drop off of scout. I turned on debug logging and see this. Not sure what other info i can grab to help. Looks like it got a nil event from slack and disconnected

[2016-04-22 18:06:51 UTC] DEBUG: presence_change event received from Slack and will be ignored.
[2016-04-22 18:07:04 UTC] DEBUG:  event received from Slack and will be ignored.
[2016-04-22 18:07:04 UTC] INFO: Disconnected from Slack.

Turn off auto formatting by default?

We are having an issue where the double quote in slack autoformats to different character.

From " to “

This is how it was resolved in hubot. Can we look at doing something in lita-slack?

slackapi/hubot-slack@47a6fa9

Allow to know if a message is coming from a bot

Not sure how this fits within the Lita gem API but something like response.user.robot? would be great.

Bot users can be detected by checking that the subtype=bot_message as it's done to check if the message is coming from the current bot

I'd be happy to submit a PR but not without agreeing on the right API first ✅

Ability to ignore single channel guests and restricted users

We're a pretty open company, thus do not whitelist Lita commands to various users - everyone can do everything. We do however open our #random channel to company alumni and other "friends of the company", we add them as single channel guests. Currently Slack doesn't allow any way to restrict direct messages - meaning any of these members can query Lita.

We don't want this is, it'd be ideal if we could disable access to Lita for users with the "is_ultra_restricted" or "is_restricted" flags on the global level.

Is there any way to get proper debug report about problem?

When i try to run some of command the only thing i get is...

[2015-07-30 18:11:04 UTC] INFO: Connected to Slack.
[2015-07-30 18:11:12 UTC] INFO: Disconnected from Slack.

Receive post-plugin message content

Using the Giphy integration as an example: when a user uses /giphy sometag, Lita receives exactly that. I would like to also know what the outcome of the command was, e.g. the URL that was posted to the channel.

(I'm concerned this is a limitation of the Slack API, but it's worth asking.)

Support for rich message formatting / attachments

Does the lita slack plugin support and rich data formatting. Slack calls this API message attachments and its linked here

Remove bot_message and me_message from supported_message_subtypes

Context: In litaio/lita#191 @jimmycuadra suggested modifying lita-slack to ignore bot messages automatically as a simpler alternative to a configurable ignore list. While following up on this suggestion, I discovered here (

lita-slack/lib/lita/adapters/slack/message_handler.rb

Line 194 in b8c527b

%w(bot_message me_message)

) that the adapter already checks the message subtype (https://api.slack.com/events/message) and allows bot_messages and me_messages to be dispatched to the robot.

I can't think of a particular scenario where this behavior is actually desirable:

In my experience, a user who wishes to send a message or command to be received by the bot will not attempt to do so with a /me message. In fact, a Lita response to a /me message is usually unexpected.
The reason given for ignoring messages from self (preventing infinite loops, see https://github.com/litaio/lita/blob/c3ae7d0d994fd0f15f5f18290920b49ca7e3441b/lib/lita/route_validator.rb#L55) also applies to messages from bots in general. For example, I added the ignore configuration option to lita-jira (esigler/lita-jira@7f8fda2) precisely because our Lita instance was responding to JIRA issue IDs it detected in messages sent by our JIRA Slack integration, resulting in spammy duplicate output.

For these reasons, I am proposing the removal of bot_message and me_message from the array of supported_message_subtypes. Pending feedback, I can submit a pull request enacting this change.

Join Channels

How does one get the bot to join other channels? Right now it is only in general and I'd like it in a few other channels. I tried lita join #random but the console outputted [2015-01-20 01:57:18 UTC] WARN: This adapter has not implemented #join. which I assume means it currently isn't implemented?

lita gets disconnected almost immediately

Stacktrace:

[2015-12-09 23:39:32 UTC] INFO: Disconnected from Slack.
/usr/local/lib/ruby/gems/2.2.0/gems/activesupport-4.2.5/lib/active_support/core_ext/object/json.rb:37:in `to_json_with_active_support_encoder': undefined method `encode' for ActiveSupport::JSON:Module (NoMethodError)
    from /usr/local/lib/ruby/gems/2.2.0/gems/multi_json-1.11.2/lib/multi_json/adapters/json_common.rb:19:in `dump'
    from /usr/local/lib/ruby/gems/2.2.0/gems/multi_json-1.11.2/lib/multi_json/adapter.rb:25:in `dump'
    from /usr/local/lib/ruby/gems/2.2.0/gems/multi_json-1.11.2/lib/multi_json.rb:136:in `dump'
    from /usr/local/lib/ruby/gems/2.2.0/gems/lita-slack-1.7.2/lib/lita/adapters/slack/rtm_connection.rb:89:in `payload_for'
    from /usr/local/lib/ruby/gems/2.2.0/gems/lita-slack-1.7.2/lib/lita/adapters/slack/rtm_connection.rb:104:in `safe_payload_for'
    from /usr/local/lib/ruby/gems/2.2.0/gems/lita-slack-1.7.2/lib/lita/adapters/slack/rtm_connection.rb:62:in `block (2 levels) in send_messages'
    from /usr/local/lib/ruby/gems/2.2.0/gems/lita-slack-1.7.2/lib/lita/adapters/slack/event_loop.rb:10:in `block in defer'
    from /usr/local/lib/ruby/gems/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1062:in `call'
    from /usr/local/lib/ruby/gems/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1062:in `block in spawn_threadpool'

This is in a container built from litaio/ruby:latest, and:

activesupport (4.2.5)
eventmachine (1.0.8)
json (1.8.3)
multi_json (1.11.2)

Happy to provide any other debugging info.

FR: Reconnect when the link is disconnected.

Today, my bot was not respond to chat.
I checked the log and I found this line.

INFO: Disconnected from Slack.

I guess the lita-slack does not reconnect when the connection is lost.
Is there any way to reconnect to slack server?

NoMethodError exception in create_user': undefined method `id'

I have had this crash happen every now and then on Heroku, not sure what triggers it.

2014-12-11T12:51:56.440184+00:00 app[web.1]: /app/vendor/bundle/ruby/2.1.0/gems/lita-slack-1.0.1/lib/lita/adapters/slack/user_creator.rb:8:in `create_user': undefined method `id' for #<Hash:0x007f34d4d78948> (NoMethodError)
2014-12-11T12:51:56.440205+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-slack-1.0.1/lib/lita/adapters/slack/message_handler.rb:61:in `handle_bot_change'
2014-12-11T12:51:56.440209+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-slack-1.0.1/lib/lita/adapters/slack/rtm_connection.rb:88:in `receive_message'
2014-12-11T12:51:56.440214+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:31:in `block in emit'
2014-12-11T12:51:56.440211+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-slack-1.0.1/lib/lita/adapters/slack/rtm_connection.rb:41:in `block (2 levels) in run'
2014-12-11T12:51:56.440215+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:30:in `each'
2014-12-11T12:51:56.440222+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/faye-websocket-0.8.0/lib/faye/websocket/api.rb:64:in `receive_message'
2014-12-11T12:51:56.440234+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:30:in `emit'
2014-12-11T12:51:56.440207+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-slack-1.0.1/lib/lita/adapters/slack/message_handler.rb:21:in `handle'
2014-12-11T12:51:56.440220+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/faye-websocket-0.8.0/lib/faye/websocket/api/event_target.rb:44:in `dispatch_event'
2014-12-11T12:51:56.440212+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:31:in `call'
2014-12-11T12:51:56.440217+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:30:in `emit'
2014-12-11T12:51:56.440225+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/faye-websocket-0.8.0/lib/faye/websocket/api.rb:33:in `block in initialize'
2014-12-11T12:51:56.440230+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:31:in `block in emit'
2014-12-11T12:51:56.440254+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-slack-1.0.1/lib/lita/adapters/slack/rtm_connection.rb:36:in `run'
2014-12-11T12:51:56.440249+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
2014-12-11T12:51:56.440262+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-4.0.4/lib/lita.rb:79:in `run'
2014-12-11T12:51:56.440228+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:31:in `call'
2014-12-11T12:51:56.440268+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
2014-12-11T12:51:56.440233+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/event_emitter.rb:30:in `each'
2014-12-11T12:51:56.440258+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-4.0.4/lib/lita/robot.rb:69:in `run'
2014-12-11T12:51:56.440239+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/hybi.rb:112:in `parse'
2014-12-11T12:51:56.440275+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-4.0.4/bin/lita:6:in `<top (required)>'
2014-12-11T12:51:56.440238+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/hybi.rb:317:in `emit_frame'
2014-12-11T12:51:56.440243+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/websocket-driver-0.4.0/lib/websocket/driver/client.rb:56:in `parse'
2014-12-11T12:51:56.440280+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/bin/lita:23:in `<main>'
2014-12-11T12:51:56.440272+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
2014-12-11T12:51:56.440267+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
2014-12-11T12:51:56.440253+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
2014-12-11T12:51:56.440244+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/faye-websocket-0.8.0/lib/faye/websocket/api.rb:79:in `parse'
2014-12-11T12:51:56.440248+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/faye-websocket-0.8.0/lib/faye/websocket/client.rb:79:in `receive_data'
2014-12-11T12:51:56.440271+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
2014-12-11T12:51:56.440257+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-slack-1.0.1/lib/lita/adapters/slack.rb:14:in `run'
2014-12-11T12:51:56.440264+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/gems/lita-4.0.4/lib/lita/cli.rb:77:in `start'
2014-12-11T12:51:56.440277+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.1.0/bin/lita:23:in `load'
2014-12-11T12:51:57.146099+00:00 heroku[web.1]: State changed from up to crashed

periodic crashing

I am currently seeing our Slack-integrated Lita instance crash fairly regularly, say every 6 hours or so, with this same backtrace every time:

/usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack/message_handler.rb:37:in `body': undefined method `sub' for nil:NilClass (NoMethodError)
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack/message_handler.rb:46:in `dispatch_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack/message_handler.rb:83:in `handle_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack/message_handler.rb:17:in `handle'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack/rtm_connection.rb:88:in `receive_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack/rtm_connection.rb:41:in `block (2 levels) in run'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:31:in `call'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:31:in `block in emit'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:30:in `each'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:30:in `emit'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/faye-websocket-0.9.0/lib/faye/websocket/api/event_target.rb:44:in `dispatch_event'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/faye-websocket-0.9.0/lib/faye/websocket/api.rb:68:in `receive_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/faye-websocket-0.9.0/lib/faye/websocket/api.rb:37:in `block in initialize'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:31:in `call'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:31:in `block in emit'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:30:in `each'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/event_emitter.rb:30:in `emit'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/hybi.rb:396:in `emit_message'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/hybi.rb:379:in `emit_frame'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/hybi.rb:118:in `parse'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/websocket-driver-0.5.0/lib/websocket/driver/client.rb:56:in `parse'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/faye-websocket-0.9.0/lib/faye/websocket/api.rb:83:in `parse'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/faye-websocket-0.9.0/lib/faye/websocket/client.rb:79:in `receive_data'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack/rtm_connection.rb:36:in `run'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-slack-1.0.2/lib/lita/adapters/slack.rb:14:in `run'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-4.0.4/lib/lita/robot.rb:69:in `run'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-4.0.4/lib/lita.rb:79:in `run'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-4.0.4/lib/lita/cli.rb:77:in `start'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /usr/local/rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/lita-4.0.4/bin/lita:6:in `<top (required)>'
    from /usr/local/rbenv/versions/2.0.0-p598/bin/lita:23:in `load'
    from /usr/local/rbenv/versions/2.0.0-p598/bin/lita:23:in `<main>'

Lita does not reconnect after team_migration_started event

Slack sometimes kicks all clients for a given team off to migrate them to another server. The lita-slack handler does not appear to try a reconnect after this occurs

[2016-06-04 05:01:28 UTC] DEBUG: team_migration_started event received from Slack and will be ignored.
[2016-06-04 05:01:28 UTC] INFO: Disconnected from Slack.
[2016-06-04 05:01:28 UTC] DEBUG: Closing connection to the Slack Real Time Messaging API.

https://api.slack.com/events/team_migration_started

(Might be related to #89 but since its not a nil event, i am creating a separate issue`

reply_privately does not work

Just like title says. If I run response.reply_privately, it just responds to room where route was triggered.