Fix: Flutter SDK path in settings is not updated#8827
Fix: Flutter SDK path in settings is not updated#8827cj-radcliff wants to merge 5 commits intomainfrom
Conversation
The settings page UI for the Flutter SDK path was not updating after being changed. When a user updated the path, applied the change, and re-opened settings, the old path would still be displayed. This was caused by the settings page reading the SDK path from a stale cache provided by the Dart plugin (FlutterSdk.getFlutterSdk()). The fix is to use FlutterSdk.getIncomplete() instead, which bypasses the cache and reads the path directly from the authoritative source: the project's Library Table configuration. This ensures the UI always displays the currently configured value. Fixes: #8641
There was a problem hiding this comment.
Code Review
This pull request correctly identifies and fixes an issue where the Flutter SDK path was not updating in the settings UI by switching from FlutterSdk.getFlutterSdk() to FlutterSdk.getIncomplete(). My review focuses on a necessary improvement to ensure thread safety. The new calls to FlutterSdk.getIncomplete() access the project model from the Event Dispatch Thread (EDT) and must be wrapped in a ReadAction to comply with the IntelliJ Platform's threading rules, as outlined in the repository's style guide. I have provided comments with code suggestions for each occurrence.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
|
|
||
| private void init() { | ||
| final FlutterSdk sdk = FlutterSdk.getFlutterSdk(myProject); | ||
| final FlutterSdk sdk = com.intellij.openapi.application.ReadAction.compute(() -> FlutterSdk.getIncomplete(myProject)); |
There was a problem hiding this comment.
Is there a reason to use qualified name instead of importing?
There was a problem hiding this comment.
+1. I don't think there's a good one. Could you fix?
pq
left a comment
There was a problem hiding this comment.
If this works, I'm OK to land it but I have to wonder why the cache is stale and if there aren't other places where getFlutterSdk(...) isn't working as expected -- looks like it's used 40+ times. 🧐
I'm also curious if this is a newly broken bit or if it's been misbehaving for a while and noone has reported it? (More just asking out loud... I don't expect an answer!)
| @Override | ||
| public void reset() { | ||
| final FlutterSdk sdk = FlutterSdk.getFlutterSdk(myProject); | ||
| final FlutterSdk sdk = com.intellij.openapi.application.ReadAction.compute(() -> FlutterSdk.getIncomplete(myProject)); |
There was a problem hiding this comment.
Let's fix this qualified reference here too.
|
More thoughts: it'd be interesting to ask gemini some follow up questions:
Including the results with the review would be great as a kind of "alternatives considered" addendum. |
|
Another question:
@cj-radcliff: it would be great to include your verification steps too. (That is: how you tested the fix.) |
|
I asked a few questions of gemini, adding here. @pq I will also ask your questions and follow up further: Explanation of Cache Fix for ReviewersQ1: Who introduced the cache and why is it used instead of reading from disk?A: The commit to fix the issue by bypassing the cache was made by Cory R on Wed Feb 25, 2026. The commit message explains that the original cached method, The reason a cache is used is for performance. Reading from disk is thousands of times slower than reading from memory. Since many parts of the IDE need the SDK path frequently, caching the value after the first read prevents redundant, slow disk operations and keeps the UI responsive. The bug occurred because the settings page, which needs the authoritative value from the disk, was incorrectly using the potentially stale cached value. The fix was to use ** NOTE! This answer is partially incorrect because its not what I asked. I include it because the second half seems to be a good answer. Q2: Does this fix cause normal access methods to read from disk more often?A: No, it does not. The fix was carefully targeted only to the settings page code ( Other parts of the plugin that use the cached Q3: Is there a way to make the fix by refreshing the cache properly before reading it, instead of bypassing it?A: While theoretically possible, bypassing the cache is the better and safer design choice in this specific context for several reasons:
|
The settings page UI for the Flutter SDK path was not updating after being changed. When a user updated the path, applied the change, and re-opened settings, the old path would still be displayed.
This was caused by the settings page reading the SDK path from a stale cache provided by the Dart plugin (FlutterSdk.getFlutterSdk()).
The fix is to use FlutterSdk.getIncomplete() instead, which bypasses the cache and reads the path directly from the authoritative source: the project's Library Table configuration. This ensures the UI always displays the currently configured value.
Fixes: #8641
Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below.