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:

1. User edits flutter sources and builds APK, installs on device.
2. User further edits source code.
3. User starts app and runs flutter attach.
4. 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

cc @zanderso @feinstein