rb-fsevent: Running worker failed error after rails server started

this is, quite possibly, my most embarrassing bug… breaking the number one user of the API (listen). Yet another reason why we should all adopt your central test suite idea, @ioquatix.

I know it’s blegh, but I also know it’ll work because I’ve seen that pattern all over the place. like… FactoryGirl has arity checks everywhere.

I guess it’s time to add an arity check. 🤷‍♂️

Thanks for the enlightening info @ioquatix. I’ll have to add tests specifically using lambdas.

v0.10.2 should fix this. Leaving the bug open so that reporters can confirm.

ruby sure has some fun edge cases. that’s for sure.

To anyone currently experiencing this issue, I apologise. I could release the above fix about checking block arity, but without understanding why my tests pass i’m going to lose my mind.

@ioquatix - The API takes a block as a callback and, until now, it has always been called with exactly one parameter. Now I call it with two parameters… but in my testing, even if you pass in a block with just one parameter caught and used, it still worked. This led me to believe you could safely ignore the second parameter and the change wouldn’t break any existing code. Obviously, I’m wrong.

ping @ioquatix - all of my local tests pass and it’s seriously breaking my mind here. the tests themselves still only use ONE parameter in the callback… just like everyone else in the world as of the 0.10.0 release. From the spec:

  before(:each) do
    @results = []
    @fsevent = FSEvent.new
    @fsevent.watch @fixture_path.to_s, {:latency => 0.3, :no_defer => true} do |paths|
      @results += paths
    end
  end

Now… I know the fix here. It’s an easy fix. Just do something to the effect of:

case callback.arity
when 1 callback.call(modified_paths)
when 2 callback.call(modified_paths, decoded)
end

But WHY don’t my tests break when apparently listen does?! I need to understand what’s going on here. I’m using what is likely the same ruby as the initial reporter as my primary ruby: ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16].

The code is running in a new thread in the tests, but that isn’t swallowing errors because I actually check the @results array in the tests!! It’s obviously running and succeeding. Where are my tests lacking to not have caught this?

Same thing here with Ruby 2.4.0, Rails 5.1.1 in macOS 10.12.5. The culprit seems to be the change in commit 2be35f19fc6691faef5b28d702093ddd2b4834ea in the callback call where is now a second parameter.

Unfortunately I didn’t unterstand enough of this code to fix it; so I made a workaround for me by adding the last working version with gem 'rb-fsevent', '= 0.9.8' in the Gemfile.

https://github.com/thibaudgg/rb-fsevent/blob/f6492c7f5fdf9cc81ff9b69dce387fc2d3fff1b7/lib/rb-fsevent/fsevent.rb#L75