Flow caches and fails to purge errors

[ubershmekel]

Flow can sometimes cache errors and requires a killall flow to show that in fact there are no errors.

See closed issue at:

#1901

[ubershmekel]

Just got this funny mistake where the error printer was aware of the update but the error checker wasn't.

12:08 $ yarn run flow
yarn run v0.23.2
$ flow 
Error: ../rylodb/src/database.js:518
518:         const promiseUser = this.queryAsync(deleteQuery, [userUuid]);
                                 ^^^ identifier `thi`. Could not resolve name


Found 1 error
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
✘-1 ~/rylo/backend/packages/api [master ↑·3|✚ 6…6] 

I guess you need an image to appreciate this one:

[asolove]

Can you give some more information on your environment: flow version, OS, etc.?

[ubershmekel]

15:45 $ uname -a
Darwin yuvmac.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
15:45 $ flow --version
Warning: `flow --version` is deprecated in favor of `flow version`
Flow, a static type checker for JavaScript, version 0.51.1

[hobofan]

I have the same problem with a similar setup:

$ uname -a
Darwin Maximilians-MacBook-Air.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64
$ flow version
Flow, a static type checker for JavaScript, version 0.51.0

The problem also persists across Flow instances. So even after killall flow, after some time the old errors reappear for me, even though the file has completely changed since then.

[massimonewsuk]

A colleague of mine is facing the same issue. He's using Ubuntu 17.04. He tried killing all flow processes, and also deleting the flow bin and reinstalling it.

However, he is still having the same problem where some errors from before are showing up.

In his specific case, it's a "module not found" error.

If you need any more info let me know. He's using version 0.64. His kernel is 4.10.x.

[im-martijn]

Same problem on Mac OS (10.13.6) using Webstorm 18.1.4.

[kangax]

Ran into this as well on macOS 10.3.3, Flow 0.80. Added // @flow strict, Flow complained about one of the modules not being strict, made that module strict, Flow still complains. Curiously, flow check seems to work whereas flow doesn't.

[armaanahluwalia]

I'm seeing this on Mac 10.13.6 High Sierra. Running rm -rf ~/.flow-typed clears the cache.

Edit: OK I'm not sure of the fix or even if I was indeed seeing this problem. Will update once I have an answer.

[ssidorchik]

My Flow version is 0.82.0 and I had exactly the same issue as @kangax described. Running rm -rf ~/.flow-typed helped to remove the errors.

[ArmorDarks]

Getting this from time to time on Windows 10, Flow 0.83.0

[pemre]

A colleague of mine is still facing the issue. He's using Ubuntu 18.04 with Flow version 0.98.1.

1. Using $ flow caches errors.
2. Using $ flow check always shows correct/expected/uncached results. But of course it's way slower.
3. Using $ flow stop and then $ flow shows expected result once and then caches again.

[pemre]

I might have found a solution.

I just realised that my colleague's Linux machine (Ubuntu 18.04 with Flow 0.98.1) had default watch limit for inotify. His PhpStorm was warning us about the limit as we have many files to watch in our project. We increased the limit as IntelliJ docs suggested and voilà! After restarting the Flow server both flow and flow check work as expected. I've already increased it months ago on my Linux machine, so I wasn't able to reproduce the problem 😃.

Here are the steps we followed:

1. Add the following line to either /etc/sysctl.conf file or a new *.conf file (e.g. idea.conf) under /etc/sysctl.d/ directory:
   fs.inotify.max_user_watches = 524288
2. Then run this command to apply the change: sudo sysctl -p --system
3. (If you use your terminal inside your IDE) Restart your IDE.
4. Stop Flow server: flow stop
5. Start Flow again: flow (also flow check should work)

⚠️ To debug if your files are being watched by Flow server, I recommend you to run it in the foreground: flow server. This way you'll be able to see whether the server "watches" for changes:

flow server
May 20 14:29:39.809 [info] argv=/project/node_modules/flow-bin/flow-linux64-v0.98.1/flow server
May 20 14:29:39.809 [info] Creating a new Flow server
May 20 14:30:12.065 [info] File watcher reported 3 files changed
May 20 14:30:27.078 [info] File watcher reported 6 files changed