This is very odd... I can repro running from source and added some prints, and it seems like it is creating the file:

PS C:\Dev\Google\flutter\packages\flutter_tools> ../../bin/dart .\bin\flutter_tools.dart --version; ls ../..
Ensuring version file (_FlutterVersionGit)!
Inside _FlutterVersionGit.ensureVersionFile
Writing 3.19.0-13.0.pre.32 to LocalFile: 'C:\Dev\Google\flutter\version' using ErrorHandlingFileSystem
Calling LocalFile("C:\Dev\Google\flutter\version").writeAsStringSync()
Calling LocalFile("C:\Dev\Google\flutter\bin\cache\flutter.version.json").writeAsStringSync()
Flutter 3.19.0-13.0.pre.32 • channel master • [email protected]:DanTup/flutter.git
Framework • revision ccb2b4439a (5 hours ago) • 2024-01-30 14:59:24 +0800
Engine • revision 438e9b4d7d
Tools • Dart 3.4.0 (build 3.4.0-82.0.dev) • DevTools 2.31.0

And nothing in the delete calls prints, so it doesn't seem like it's being deleted.

I'll try to debug a bit more shortly... This could be a big issue if widespread, because VS Code uses this version to switch quite a bit of Dart-Code functionality.

@christopherfujino here is the issue:

Inside _FlutterVersionGit.ensureVersionFile
Writing 3.19.0-13.0.pre.32 to LocalFile: 'C:\Dev\Google\flutter\version' using ErrorHandlingFileSystem
Calling LocalFile("C:\Dev\Google\flutter\version").writeAsStringSync()
Exists now? true
Calling LocalFile("C:\Dev\Google\flutter\bin\cache\flutter.version.json").writeAsStringSync()
Exists now? true
Deleting the new version file!!!!!!
Deleting the legacy version file!!!!!!

The files are being deleted by:

Stack trace is like:

#0      new FlutterVersion (package:flutter_tools/src/version.dart:111:26)
#1      FlutterVersion.fetchTagsAndGetVersion (package:flutter_tools/src/version.dart:178:12)
#2      FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:338:65)
<asynchronous suspension>
#3      AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:19)
<asynchronous suspension>
#4      FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:294:5)

It's created here on line 311 and then deleted because of the call on line 338:

Doesn't seem to affect beta, but I haven't yet figured out why, since most of the code seems the same.

Ok, the reason this doesn't happen on beta is because of this early exit, which prevents the constructor running that deletes the file:

So the issue is isolated to branches named master/main.

Thanks for the detailed report and analysis. Labeling this for tracking.

@christopherfujino leaving to you for prioritizing

Not sure if it's the same thing, but I just noticed that the GitHub actions are often failing the coverage step because the Flutter version is reported as 0.0.0-unknown:

Example: https://github.com/flutter/flutter/actions/runs/8999603670/job/24722091985

Not sure if it's the same thing, but I just noticed that the GitHub actions are often failing the coverage step because the Flutter version is reported as 0.0.0-unknown:

Example: https://github.com/flutter/flutter/actions/runs/8999603670/job/24722091985

TIL we try to upload coverage from actions

This came up again in Dart-Code/Dart-Code#5226, where we were using old versions of DevTools page IDs because we thought we were on an old version of the Flutter SDK.

@christopherfujino @andrewkolos does anyone know why we have a difference in this path for master/main? If we remove the if statement quoted above (so that master/main did the same as other branches, and never triggered the delete), would anything break? 🤔

@christopherfujino @andrewkolos does anyone know why we have a difference in this path for master/main? If we remove the if statement quoted above (so that master/main did the same as other branches, and never triggered the delete), would anything break? 🤔

We have a difference on master/main because what we report as the version changes as new tags are added upstream. If we removed the if statement, once we cache the version, this would remain as long as you're on the same commit, even if we publish a beta from an OLDER commit, and our version should now reflect that it is AFTER the beta.

Ah, gotcha. Should there be an ensureVersionFile call somewhere after that fetchTagsAndGetVersions() then? Oddly, I can't see where fetchTagsAndGetVersions() (or the constructor it calls) actually fetches any tags (seems like it just calls gitLog 🤔).

Some additional info I just noticed:

• running flutter doctor results in the file being deleted and not replaced
• running flutter --version results in the file being deleted and not replaced
• running flutter --help results in the file remaining (or not being deleted)

Seems like Dart-Code is triggering this sometimes when you have a Flutter SDK with no Dart SDK because we force it to initialize by calling flutter doctor (and showing the output to the user). If we call flutter --help afterwards, then we'll have a good version number, but it is slightly weird.

Some additional info I just noticed:

• running flutter doctor results in the file being deleted and not replaced
• running flutter --version results in the file being deleted and not replaced
• running flutter --help results in the file remaining (or not being deleted)

Seems like Dart-Code is triggering this sometimes when you have a Flutter SDK with no Dart SDK because we force it to initialize by calling flutter doctor (and showing the output to the user). If we call flutter --help afterwards, then we'll have a good version number, but it is slightly weird.

Let me carve out some time today to dig in a little bit. I'll take me a while to get back up to speed on all the convoluted logic here (I remember thinking I could implement this in a few days, but it actually took me weeks, I've already had to fix a bad bug, and clearly there's another one).

Thanks! I implemented a few tweaks in Dart-Code (such as calling flutter --help directly after flutter doctor in the case where we force initialization) which I think will reduce the chance of hitting this, but it's pretty hacky and it'd be nice to remove them if it's not a ton of work here.

@DanTup Ahh, as I read this issue carefully, am I correct in understanding that dart-code is parsing $FLUTTER_ROOT/version in order to conditionally disable some features? If that is the case, the fix here is migrating to use $FLUTTER_ROOT/bin/cache/flutter.version.json.

I (mistakenly) thought that the only tool that was reading this was pub, which was migrated here: dart-lang/pub#4113.

Does devtools also parse this file @kenzieschmoll ?

Ah, that sounds reasonable. Currently we're just reading the version the same way for Dart and Flutter (Dart also has a version), but reading the JSON if it is there should work too. If it's only the "legacy" file being removed, this will remove the need for my other workaround too. I've filed Dart-Code/Dart-Code#5231 about this.

I've switched Dart-Code to reading the new JSON file first and just using the legacy version file if it fails to find (or parse a version from) the JSON file.

As such, I/Dart-Code doesn't care so much about this behaviour now - if this version file is considered legacy and shouldn't be used, this issue could be closed.

(although it may also be worth checking with @helin24 / @jwren whether IntelliJ uses the original file)

Ahh, as I read this issue carefully, am I correct in understanding that dart-code is parsing $FLUTTER_ROOT/version in order to conditionally disable some features? If that is the case, the fix here is migrating to use $FLUTTER_ROOT/bin/cache/flutter.version.json.

Today I noticed that this file is also not present in my Flutter checkout. Combined with the version file missing, that means Dart-Code is currently treated the Flutter version as unknown (and as 999.999 for all version checks).

If I run an invalid command like flutter foo, the file appears (as does the legacy one), but if I then run flutter doctor, the files both get deleted again.

So it seems that migrating to the new version file hasn't actually solved the problem.

I (mistakenly) thought that the only tool that was reading this was pub, which was migrated here: dart-lang/pub#4113.

Does devtools also parse this file @kenzieschmoll ?

Late on the response here... but this is the only other place I am aware of. It looks like it is using the correct file path:
https://github.com/dart-lang/sdk/blob/master/pkg/dtd_impl/lib/src/service/unified_analytics_service.dart/#L158

I'm assuming this is still an issue @DanTup?

@bkonyi it is. Here you can see both the legacy version file and the flutter.version.json file disappear when I run flutter doctor (and both come back when I run flutter help):

@bkonyi Any progress? I think this is possibly also the cause of #157627.

Any progress? I think this is possibly also the cause of #157627.

Nope, I haven't had a chance to look into this and probably won't for a while. I'm the only one on the tools team at the moment so I don't have cycles to investigate, I just didn't want this triaged issue to disappear into the void by leaving it unassigned.

I had some time to look into this, and it looks like we're deleting the version files when we [create a FlutterVersion instance with fetchTags == true:

    // if we are fetching tags, ignore cached versionFile
    if (fetchTags && versionFile.existsSync()) {
      versionFile.deleteSync();
      final File legacyVersionFile = fs.file(fs.path.join(flutterRoot, 'version'));
      if (legacyVersionFile.existsSync()) {
        legacyVersionFile.deleteSync();
      }
    }

AFAICT, there's not a follow up call to FlutterVersion.ensureVersionFile() when we take that path when there probably should be. I'll pull together a quick PR to fix this.