Build Runner (2.7.0) sometimes fails to watch Files

[HeftyCoder]

EDIT: This issue generally seems to appear after building the application at least once (either in debug or release).

Upgraded Flutter from 3.32.8 to 3.35.1 and build_runner from 2.5.x to 2.7.0. Watching files with dart run build_runner watch failed multiple times:

Failed to watch files in package:<package_name>.
PathNotFoundException: Directory listing failed, path = <relative_path>my_app\build\flutter_plugin_android_lifecycle\.transforms\8afebd18f8d6cab29a4e7940b859a844\transformed\bundleLibRuntimeToDirDebug\bundleLibRuntimeToDirDebug_dex\io\flutter\embedding\engine\plugins\lifecycle\*' (OS      

  , errno = 3)

I tried flutter clean, and then re-running the build_runner. It then returned the below error once, before returning the same error as above after retrying.

Failed to watch files in package:my_app.
FileSystemException: Directory watcher closed unexpectedly, path = '<relative_path>_my_app

I ran flutter clean for a second time, restarted the PC and attempted to watch again. Got the second error once more. Finally, after re-running the watcher, things seem to work fine until we build the app.

On a side-note, while this behavior persisted, I also noticed that running dart run build_runner build would not output the results directly to the files. I'm not entirely sure what it was, but I either had to wait some time or re-ran the command until the changes were visible.

---

The attempted to watch directory is the main app directory, which contains pubspec.yaml, build.yaml etc.

• The Dart SDK Version: 3.9.0 (stable)
• Flutter Version: Flutter 3.35.1
• Development Platform: Windows
• Build Target: Android
• Excluded the dart analysis server as well as the project from Windows Defender.
• Packages include drift_builder, json_serializable, freezed, go_router_builder, and riverpod_generator.

build.yaml, for completeness:

targets:
  $default:
    builders:
      drift_dev:
        options:
          store_date_time_values_as_text: true
          apply_converters_on_variables: true
          named_parameters: true
          write_to_columns_mixins: true

[davidmorgan]

Thanks for filing.

My guess is it's due to Flutter writing temporary files to build at the same time as build_runner is trying to watch it. I'll dig a little and see if I can figure something out.

[reidbaker]

running flutter build apk from packages/packages/flutter_plugin_android_lifecycle/example
There are a lot of files written to that directory, 1955 files for my most recent run.

That directory and what files are put there is mostly controlled by AGP (basically the android build tooling)

[davidmorgan]

@reidbaker would it be correct to say that in a Flutter package, the build folder in the package root is only for outputs?

--> should I hardcode that for a Flutter package, it never watches the build folder?

[reidbaker]

I think that is a safe assumption. If it is not then it is likely we (or some other tool) is configuring something incorrectly and we can fix it with a more targeted exemption or by fixing our configuration.

[reidbaker]

I would discourage excluding all directories named build and encourage excluding all directories named build in the sub folders we expect an android build subfolder to exist.

[HeftyCoder]

The issue still persists, seemingly when building at least once (potentially both a debug and a release build cause the problem).

Seems like a flutter clean fixes things until the next build.

My guess is it's due to Flutter writing temporary files to build at the same time as build_runner is trying to watch it.

seems to be on the right track.

[HeftyCoder]

When this issue persists, the usability of build_runner is reduced tremendously. Changes aren't reflected directly in the generated files and either multiple builds or a restart of VS Code is needed for the changes to take effect.

[davidmorgan]

@HeftyCoder could you maybe try using build_runner 2.5.0 and see if anything changes?

As far as I know there are no related changes in 2.6.0 or 2.7.0, but if you switch back and the problem goes away, then obviously there are :)

It would be interesting if you could try the old Flutter with build 2.7.0 as well, that would tell us if it's a Flutter change.

I found a reference to what seems to be the underlying issue, too many file changes causing the file watcher on Windows to stop working

dart-lang/sdk#49286

which makes sense, it's just not clear why you start seeing it now.

[HeftyCoder]

I've tried every combination, and the only constraint for the watching to work was build_runner set to 2.5.4.

The issue seems to be with the removal of --use-polling-watcher (which, I think has been removed from 2.6.0 despite documentation for it being updated for 2.7.0).

When I run without --use-polling-watcher in 2.5.4, I get:

Error from directory watcher for package:praxis_flutter
If you see this consistently then it is recommended that you enable the polling file watcher with --use-polling-watcher.
PathNotFoundException: Directory listing failed, path =
'c:\<relative_path>\my_app\build\flutter_plugin_android_lifecycle\.transforms\7573d8baf3c927daa48180e573b62867\transformed\bundleLibRuntimeToDirDebug\bundleLibRuntimeToDirDebug_dex\io\flutter\embedding\engine\plugins\lifecycle\*' (OS, errno = 3)

[davidmorgan]

Oh ... were you using --use-polling-watcher up until now?

That would certainly explain it.

[HeftyCoder]

Yes, sorry for omitting this. I had been using --use-polling-watcher since around 3 months ago. I removed it as I saw the new documentation, but since it was quite awhile back, I had forgotten why I was using it.

Is there any solution to this? Or do I stick to 2.5.4?

[davidmorgan]

Great, now that makes sense :)

I'll figure out a fix, in the meantime, yes, sticking to a version with --use-polling-watcher is the way to go.

[davidmorgan]

A few more questions, if you don't mind sharing a bit more:

• what version of Windows are you on
• what version of package:watcher?

[davidmorgan]

I think I have enough to go on now, I was able to repro the underlying issue outside of build_runner: a simple file_watcher watch, then enter a sync block so that no events will be handled, while writing lots of files to trigger lots of events.