New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File changes are not always detected after updating to Meteor v1.5.1 #8942

Closed
arggh opened this Issue Jul 23, 2017 · 18 comments

Comments

@arggh
Contributor

arggh commented Jul 23, 2017

After updating to v1.5.1 (could also have been v1.5.0), I sometimes find myself in a situation where the app is acting strange and upon further inspection, the code I have on disk is different from code I have loaded in the browser.

This just happened today, again:

bug

VS Code on the left with the file saved, Chrome Dev Tools on the right showing the loaded javascript from where the error originated

I had commented out a piece of my code to prevent this specific error from happening, but it did anyway.

I haven't figured out a sure way to reproduce this yet, but I would start with moving or renaming files or folders, though this is just a hunch.

@chrishearn

This comment has been minimized.

Contributor

chrishearn commented Jul 23, 2017

I'm experiencing the same problem. I was on 1.5 for several weeks and had no issues - they only started when I upgraded to 1.5.1 so think it must be related to the file watcher changes that were introduced. I use Webstorm (on OSX Sierra) so guess this rules out it being an IDE specific problem.

@chrishearn

This comment has been minimized.

Contributor

chrishearn commented Jul 23, 2017

I'm just trialling the METEOR_WATCH_PRIORITIZE_CHANGED option to see if that makes any diffference. I will report back shortly.

@chrishearn

This comment has been minimized.

Contributor

chrishearn commented Jul 23, 2017

I can confirm that setting the METEOR_WATCH_PRIORITIZE_CHANGED environment variable to false has resolved the problem for me.

@rijk

This comment has been minimized.

rijk commented Jul 24, 2017

Yes, same here! Thought I was going crazy at first. I posted it in the forum: https://forums.meteor.com/t/rebuild-sometimes-skips-files-since-1-5-1/38104.

@hwillson

This comment has been minimized.

Member

hwillson commented Jul 24, 2017

Hi all - are the changes being detected after waiting a bit (up to 5 seconds), or are they never showing up at all?

@arggh

This comment has been minimized.

Contributor

arggh commented Jul 24, 2017

For me they would not get picked up at all, or then there's a really long delay (minutes, not seconds).

@JackAdams

This comment has been minimized.

JackAdams commented Jul 24, 2017

I can reliably create a repro for one variant of this:

  1. Take a html file (call it test.html) with a blaze template <template name="test"></template>
  2. In the mac finder, duplicate the file (a rebuild will happen and hot reload and, on the client console, there will be an error message that there are two templates with the name test).
  3. Rename the duplicated file to new-test.html (a rebuild will happen and hot reload and, on the client console, there will be an error message that there are two templates with the name test).
  4. Edit the contents of new-test.html so that it has <template name="new_test"></template>. On saving, the client will rebuild, hot reload, but the error message in the client console will still be there, even though there are no longer templates with the same name in the codebase being watched.

After getting into this state, subsequent changes to the file new-test.html, don't help (although they result in client rebuilds). There must be a cached version of test-copy.html that resulted from duplicating the file that's sneaking into the build.

The only way to fix it is to stop the meteor process and start it again, then wait while the whole project builds from scratch again.

@hwillson hwillson added the confirmed label Jul 24, 2017

@hwillson

This comment has been minimized.

Member

hwillson commented Jul 24, 2017

I haven't had a chance to dig into this much further, but I have been able to verify that the issue outlined in the above repro steps is coming from re-using existing file watchers. Commenting out

return entriesByIno.get(ino);
fixes the issue (since this ensures a new file watcher is created after every change). This of course isn't a solution, but it helps point towards the real source of the problem. For some reason the re-used watcher is no longer capturing changes. I'll dig into this more hopefully later today, but if anyone is interested in taking a look sooner, the problem lies somewhere in https://github.com/meteor/meteor/blob/b52c6587d7542c0f27481a3bee8c65be06068ac1/tools/fs/safe-watcher.js.

@hwillson hwillson self-assigned this Jul 25, 2017

@hwillson

This comment has been minimized.

Member

hwillson commented Jul 25, 2017

I've found the issue - fix coming shortly.

@hwillson

This comment has been minimized.

Member

hwillson commented Jul 28, 2017

A fix for this has been merged and will be coming in Meteor 1.5.2. Closing - thanks!

@hwillson hwillson closed this Jul 28, 2017

benjamn added a commit that referenced this issue Aug 11, 2017

Immediately dirty optimistic functions when relevant paths modified.
Should fix #8988 and #8942.

Now that #8866 is the default behavior, it can take up to 5000ms for
changes to files modified during the build process to be noticed.

Before #8866, when we called e.g. files.writeFile(path), a native file
watcher would notice the change immediately, almost always before the
build process read the file again. This was definitely racy, but we were
getting away with it consistently... until #8866.

I was able to reproduce the problem in #8988 by running

  echo some-local-package-name >> .meteor/packages

in an app with a local package of the given name. After debugging the
endless rebuild cycle, I found that .meteor/versions was being rewritten
by files.writeFile during the build process, but the file watching system
was not noticing the change in time to prevent watch.isUpToDate from
returning true. The change was finally detected when restarting the
Watcher responsible for .meteor/versions, which of course triggered
another rebuild, so the same problem kept happening again and again.

benjamn added a commit that referenced this issue Aug 11, 2017

Immediately dirty optimistic functions when relevant paths modified.
Should fix #8988 and #8942.

Now that #8866 is the default behavior, it can take up to 5000ms for
changes to files modified during the build process to be noticed.

Before #8866, when we called e.g. files.writeFile(path), a native file
watcher would notice the change immediately, almost always before the
build process read the file again. This was definitely racy, but we were
getting away with it consistently... until #8866.

I was able to reproduce the problem in #8988 by running

  echo some-local-package-name >> .meteor/packages

in an app with a local package of the given name. After debugging the
endless rebuild cycle, I found that .meteor/versions was being rewritten
by files.writeFile during the build process, but the file watching system
was not noticing the change in time to prevent watch.isUpToDate from
returning true. The change was finally detected when restarting the
Watcher responsible for .meteor/versions, which of course triggered
another rebuild, so the same problem kept happening again and again.
@davidjytang

This comment has been minimized.

davidjytang commented Sep 4, 2017

In the mean time before 1.5.2 release, where do I set METEOR_WATCH_PRIORITIZE_CHANGED?
Do I do like this?

export METEOR_WATCH_PRIORITIZE_CHANGED=false
meteor build ...

I'm experiencing meteor build keep giving me old iOS project.

@rijk

This comment has been minimized.

rijk commented Sep 14, 2017

This is still happening on 1.5.2! @hwillson

I am 100% certain. When saving multiple files at once (cmd alt S in Atom), not all files are actually processed in the rebuild.

@arggh

This comment has been minimized.

Contributor

arggh commented Sep 14, 2017

I've noticed the same. Sometimes only killing the meteor process helps to get some files back under "watching".

@chrishearn

This comment has been minimized.

Contributor

chrishearn commented Sep 14, 2017

Also still having the issue in 1.5.2. I've recently moved from WebStorm to VS Code but don't think that is relevant anyway as it appears to be happening regardless of editor/IDE from the other reports here.

I'm sticking with the METEOR_WATCH_PRIORITIZE_CHANGED=false as a current workaround, which does the trick.

Let me know if you need any more information or need any testing carried out that could help diagnose the problem.

@chrishearn

This comment has been minimized.

Contributor

chrishearn commented Sep 14, 2017

I'm working on reasonably large project, so not sure if this has any relevance, as clearly not everyone is hitting this issue:

image

Might be worth comparing if anyone else here can provide similar info from their affected projects?

@ahmadsholehin

This comment has been minimized.

ahmadsholehin commented Oct 22, 2017

I can confirm that this issue still persists. METEOR_WATCH_PRIORITIZE_CHANGED=false didn't manage to solve my issue.

@cormip

This comment has been minimized.

cormip commented Nov 20, 2017

I'm experiencing this issue with Meteor 1.6. METEOR_WATCH_PRIORITIZE_CHANGED=false did not solve the problem for me.

@Zusurs

This comment has been minimized.

Zusurs commented Jan 19, 2018

Same here. 1.6 and terrible long (up to 15 seconds) file change detection on Windows machine. METEOR_WATCH_PRIORITIZE_CHANGED=false didn't help as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment