Repository navigation
flutter attach should not assume that the application dill and local filesystem are in sync #38320
Description
During flutter run, a dill file (1) contain all sources is built and bundled into the APK/IPA that is installed onto the device. Then, when the tool attaches to the observatory for debugging and hot reload, it initializes the frontend server from the existing dill file and recompiles all sources (2). For here on out, any time a hot reload is requested, the filesystem is stat'd and updated sources are passed into the frontend server. This produces an incremental dill based on the updated sources and the state of (2). By construction (1) and (2) are identical files, so this works as expected.
During flutter attach, an APK/IPA that has already been built in some other tool/process/session is started on a device. This must contain a dill file (1) from some previous compile. We connect to the observatory and initialize the frontend server from an existing dill file (if it exists) and recompile all sources into a new dill file (2). For here on out, any time a hot reload is requested, the filesystem is stat'd and updated sources are passed into the frontend server. Unlike flutter run, there is no guarantee that (1) and (2) were the same file.
Consider the following sequence of user actions:
- User edits flutter sources and builds APK, installs on device.
- User further edits source code.
- User starts app and runs flutter attach.
- User requests hot reload, changes from (2) are not observed.
By the time the tool has reached (4), it assumes based on the flutter run workflow that the initial compile from the frontend server represents the source of truth. Therefore the hot reload does not result in any changes, since in this case the stat tells us the file was updated prior to the compile.
Fix:
In the case of flutter attach, the first hot reload should assume that every source file has been invalidated. This will significantly slow down the first reload, but will not effect subsequent reloads.
See also: #37976
Activity
zanderso commentedon Aug 12, 2019
Is it also the case that a sufficiently speedy person (or bot/ide) could modify sources between (1) and (2) during
flutter run?jonahwilliams commentedon Aug 12, 2019
Yes, that's a good point. I'll confirm locally but changes after the APK/IPA has been built but before the attach are likely to be lost in the run case as well.
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
9 remaining items
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
4fe6206 Revert "Roll Dart SDK from 358d0d1aa3e7 to 1dd5b1bf1099 (7 re…
Roll Flutter Engine from 2919651 to d91e208 (29 revisions) (#117242)
Roll Flutter Engine from 2919651 to d91e208 (29 revisions) (flutter#1…
jonahwilliams commentedon Jan 25, 2023
I'm closing this issue because I don't think this is possible to fix in a way that is generally useful. Performing a hot restart to bring things in sync is not particularly expensive, but doing it every time adds a lot of overhead
feinstein commentedon Jan 26, 2023
But wouldn't it be needed only once, after flutter attach has started?
github-actions commentedon Mar 4, 2023
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.