Repository: flutter
Issue: [flutter_tools] On Windows, running a dart process with an aot snapshot vendored as part of the Dart SDK will cause flutter upgrade to crash
Labels: P2,team-tool,triaged-tool

On Windows, running a dart process with an aot snapshot vendored as part of the Dart SDK will cause flutter upgrade to crash. Context for this issue was originally in https://github.com/flutter/flutter/issues/146164#issuecomment-2040805169, my summary of which I have copy pasted here:

1. The disk i/o implementations of `dart.exe foo.appjit.snapshot` and `dartaotruntime.exe foo.aot.snapshot` are different in that the latter will keep the snapshot file open for the duration of VM execution while the former will (presumably) close it after having read the data. I verified this with running a minimal dart program that runs indefinitely from both appjit and aot snapshots, and from another powershell session tried calling `Rename-Item` on the snapshot file--the rename succeeded on the appjit snapshot but failed on aot snapshot with `Rename-Item : The process cannot access the file because it is being used by another process.`.
2. version 4.0.0 of `frontend_server_client` is changing the package:test runner to use an aot snapshot of the frontend_server rather than an appjit snapshot: https://github.com/dart-lang/webdev/pull/2263.
3. The tool's [batch_entrypoint_test](https://github.com/flutter/flutter/blob/75ae44df77aef3d109add07abfd88438732bbee8/packages/flutter_tools/test/integration.shard/batch_entrypoint_test.dart) is validating the logic in Flutter's [update_dart_sdk.ps1](https://github.com/flutter/flutter/blob/75ae44df77aef3d109add07abfd88438732bbee8/bin/internal/update_dart_sdk.ps1) powershell script. Of interest to this issue is that at [line 74](https://github.com/flutter/flutter/blob/75ae44df77aef3d109add07abfd88438732bbee8/bin/internal/update_dart_sdk.ps1#L74), before downloading a new version of the Dart SDK, we call `Rename-Item` on the existing (or old) Dart SDK to move it to a path with `dart-sdk.old` in the name. I believe we do this because just deleting the old one while the tool is running would fail.
4. The fact that this test is failing after this change to the frontend_server_client depended on by the test runner is incidental to the specific behavior the test is running, and thus Derek's proposed test changes would make sense there.
5. The fact that this test is failing inadvertently revealed what I believe would be a real customer regression, in that when calling `flutter upgrade`, if there is any running dart process that is using an aot snapshot from the Dart SDK within the Flutter SDK's cache, `flutter upgrade` would likely fail at the step where it tries to download the new version of the Dart SDK. Re-running the flutter CLI tool would likely repeatedly fail as long as said Dart process is running.

At HEAD, the contents of //flutter/bin/cache/dart-sdk/bin/snapshots is:

analysis_server.dart.snapshot
dart2js.dart.snapshot
dart2wasm_product.snapshot
dartdevc.dart.snapshot
dartdev.dart.snapshot
dart_tooling_daemon.dart.snapshot
dds.dart.snapshot
frontend_server_aot.dart.snapshot
frontend_server.dart.snapshot
gen_kernel_aot.dart.snapshot
kernel-service.dart.snapshot
kernel_worker.dart.snapshot

It is my understanding that all of the appjit snapshots above will imminently be migrated to aot snapshots, thus increasing the likelihood that one of them is actively running when a user executes `flutter upgrade`.

FYI @a-siva @zanderso @derekxu16 @jacob314 @anderdobo