Handle received data asynchronously

[sarahzrf]

See #92.

[dblock]

This looks good. Can you please update CHANGELOG. Could use a test maybe too?

[dblock]

The build is breaking for some other reason (something wrong with vcr, possibly just need to lock down that one to a previous release - can you please check it out - I am happy to fix if it's too difficult).

[sarahzrf]

What kind of test could I write that wouldn't be extremely nondeterministic?

[dblock]

I would just make sure that the function implemented by the bot command is invoked via async, so somewhere I'd have something like expect(...).to receive(:async).and_.... But if it's too complicated it's fine without it.

[sarahzrf]

Oh, I could probably have the first command sleep indefinitely for the test. I'll try implementing that soon.

[sarahzrf]

OK, it looks like it'd be fairly complicated to write a test. I might be able to figure something out, but it'd definitely take a lot of digging and learning about how the library and its tests are set up.

[dblock]

This looks good. Could you please try to fix the build or let me know if you can't?

[sarahzrf]

It looks like the issue is with vcr - there was a new minor version released today.

[sarahzrf]

vcr/vcr#582

[dblock]

Lock vcr to 3.0.1 in this PR?

[sarahzrf]

ok - but it seems like kind of an inappropriate place to do it.

[sarahzrf]

The issue on the vcr repo suggests that this should fix it too

[sarahzrf]

ok nvm, I'll just fix the vcr version.

[dblock]

Ha, it's now failing with another issue around bundler. That's rubygems/bundler#3558 and the fix is to update bundler:

before_install:
   - gem update bundler

Please. I just want this build to be green.

[sarahzrf]

Wait - would you prefer that I undo the last commit and just lock the vcr version, or add bundler update instead?

[dblock]

Honestly I don't have a preference. It's just mechanics.

[sarahzrf]

The build is passing

[dblock]

Merged, thanks.