guard / listen

The Listen gem listens to file modifications and notifies you about the changes.
https://rubygems.org/gems/listen
MIT License
1.92k stars 246 forks source link

Failed tests on JRuby and Linux #449

Closed junaruga closed 3 years ago

junaruga commented 6 years ago

Right now unit tests are failed on the combination of JRuby and Linux. https://travis-ci.org/guard/listen/builds/388150615

For example below test case that is one of failed test cases.

  1) Listen with one listen dir force_polling option to false when :ignore is *ignored_dir* when :ignore is bar.rb when :only is *.rb should process addition of "file.rb"
     Failure/Error: it { is_expected.to process_addition_of('file.rb') }
       expected {:modified=>[], :added=>[], :removed=>[]} to include addition of file.rb
     # ./spec/acceptance/listen_spec.rb:231:in `block in (root)'
     # ./spec/acceptance/listen_spec.rb:17:in `block in (root)'
     # ./spec/support/fixtures_helper.rb:20:in `fixtures'
     # ./spec/acceptance/listen_spec.rb:17:in `block in (root)'

However when I ran below command to run the target test case only, the case was passed even on the combination of JRuby and Linux.

$ bundle exec rspec spec/acceptance/listen_spec.rb:231

See my Travis CI for debug: https://travis-ci.org/junaruga/listen/builds/389763418

Is this fact hint to fix the issue for you?

junaruga commented 6 years ago

https://travis-ci.org/guard/listen/builds/388150615 It looks current build fixes the test failure. But there are still errors by simplecov.

junaruga commented 6 years ago

My pull-request for coveralls to use latest simplecov was merged. https://github.com/lemurheavy/coveralls-ruby/pull/133

Then the new version 0.8.22 was released right now. https://rubygems.org/gems/coveralls

Let's run Travis CI.

junaruga commented 6 years ago

Umm? simplecov's error has been already disappeared and there are the test failures on master branch's Travis CI again.

eli-darkly commented 5 years ago

I have no idea if this is related, but I'm also seeing intermittent failures on JRuby 9.1.17 + Ubuntu. The symptom is that a modification to a file in a watched directory just isn't detected (although sometimes it does work). The modification was made at least 1 second after the listener was started, so I don't think the problem would be related to file time resolution.

It's always worked correctly for me on all non-JRuby versions, and also on JRuby 9.2.0. I'm using listen 3.1.5.

eli-darkly commented 5 years ago

When I turn on debug logging with LISTEN_GEM_DEBUGGING=2, on the rare test runs that actually pass, I get output like this:

DEBUG -- : inotify: my-file-name ([:close_write, :close])
DEBUG -- : modified: file:/my/directory/path/my-file-name ({:change=>:modified})
DEBUG -- : listen: raw changes: [[:modified, "/my/directory/path/my-file-name"]]
DEBUG -- : listen: final changes: {:modified=>["/my/directory/path/my-file-name"], :added=>[], :removed=>[]}

But when the test fails, the last two lines are omitted. That is, it still detects the file change and puts it on the queue (in Change.invalidate) but then either Processor._process_changes does not get executed, or else somehow it does get called but no longer sees changes in the queue - either way, config.optimize_changes is not being called (processor.rb line 110).

eli-darkly commented 5 years ago

That makes me suspect that the problem is not actually in the file-watching logic, but in the Processor - like maybe it does not get woken up from its sleep when an event is added. But I looked through the fixed issues from the JRuby 9.2 release but couldn't find anything related to thread scheduling or sleeps, so I don't know if that makes sense. Also, if it's not anything kernel-related then I would not expect it to behave differently in Ubuntu than in Darwin, but it does - I never see these failures on a Mac.

ColinDKelley commented 3 years ago

There were race condition bugs in the Processor where it might call thread.wakeup before the thread called sleep. When that happened, changes would be missed. That might explain this bug. These race conditions are fixed in #481 , which will be released shortly in v3.3.

@eli-darkly Any chance you could try v3.3.0.pre.2 and see if it fixes this issue?

ColinDKelley commented 3 years ago

Or maybe it's sufficient that the CI builds have been green for a while?

eli-darkly commented 3 years ago

@ColinDKelley - Afraid I can't be of help here, because our project has already dropped support for JRuby 9.1 which was the only platform we'd seen the error in.

ColinDKelley commented 3 years ago

Ok, thanks @eli-darkly. I think we'll close out this ticket for now. If a new problem comes up, feel free to file a new ticket. We'll at least make sure to keep the CI builds green across the matrix.