fix: expire stale notifications in all code paths (#8914)

[khusantoy]

What this PR changes and why

Every hot reload and hot restart posted a "Reloading…" notification
via showRunNotification(). These entries were never expired before a
new one was posted, so they accumulated in the IDE Notifications
timeline and buried important alerts (e.g. "Shortcuts conflicts").

Three code paths are fixed:

1. showRunNotification() — expires the previous notification before
   posting a new one (guarded by !isError so genuine error
   notifications remain visible).
2. showAnalysisNotification() — same fix for "Reload not performed"
   / "Analysis issues found" messages.
3. clearLastNotification() — now calls .expire() before nulling
   the reference, so toolbar/shortcut-triggered reloads also clean up
   stale timeline entries.

Relevant issues

Fixes #8914

How to verify

1. Open any Flutter project in Android Studio / IntelliJ.
2. Run the app in debug mode.
3. Trigger hot reload 5+ times (Cmd+S or toolbar button).
4. Open the Notifications panel (bell icon, top-right) → Timeline view.

Before: multiple "Reloading…" entries accumulate in the timeline.
After: only the most recent entry is visible; previous ones are expired.

Screenshots

No UI changes — behaviour is in the IDE Notifications timeline.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request incorrectly commits the local.properties file, which contains local SDK paths specific to the developer's machine and should be ignored. Additionally, the actual implementation changes described in the PR title and description appear to be missing. The reviewer requested removing local.properties from the repository, adding it to .gitignore, and committing the correct files.

[gemini-code-assist]

[MUST-FIX] The local.properties file contains local SDK paths specific to your machine and should not be committed to version control. Tracking this file can break builds on other developers' machines and CI/CD environments.\n\nPlease remove local.properties from the repository and ensure it is ignored via .gitignore.\n\nAdditionally, it looks like the actual implementation changes for expiring stale notifications (as described in the PR title and description) were not included in this pull request. Please commit the correct files.

References

1. Prefix every comment with a severity category such as [MUST-FIX]. ^(link)

[helin24]

I'm not able to test this myself, because I don't see any balloons for hot reload/restart. Before we merge I want to make sure I'll be able to manually test this for an upcoming release. Could you tell me what settings you have for notifications?

[khusantoy]

I'm not able to test this myself, because I don't see any balloons for hot reload/restart. Before we merge I want to make sure I'll be able to manually test this for an upcoming release. Could you tell me what settings you have for notifications?

I have both "Display balloon notifications" and "Enable system notifications" enabled. For Flutter-related notification groups (Flutter Messages, Flutter Notifications, flutter-run, flutter-debug, etc.) the popup type is set to "Balloon".

[helin24]

Ah okay, I also had to check "show in tool window" for the individual groups; otherwise I wasn't seeing them in the notifications timeline. I also realized that initially I wasn't seeing them because I hadn't enabled hot reload on save (no notifications show up if you click hot reload or hot restart).

Are you able to test this locally and see it work? I checked out this branch but still see multiple notifications:

It could be there are other settings modifications I need to make. Do you have any suggestions?

[khusantoy]

Ah okay, I also had to check "show in tool window" for the individual groups; otherwise I wasn't seeing them in the notifications timeline. I also realized that initially I wasn't seeing them because I hadn't enabled hot reload on save (no notifications show up if you click hot reload or hot restart).

Are you able to test this locally and see it work? I checked out this branch but still see multiple notifications:

It could be there are other settings modifications I need to make. Do you have any suggestions?

I don't think I changed any extra settings. Everything should be using the default configuration on my machine

[helin24]

Hmmm... sorry for the delay getting back to you; I wanted to investigate this a little further.

In my system, this doesn't seem to work, and gemini suggests it's because these are tool window notifications and the associated balloon in the tool window does not get hidden when Notification.expire() is called:

Why lastNotification.expire() alone doesn't dismiss the notification

1. TOOL_WINDOW Display Type in IntelliJ:
   • The notification groups (flutter-run and flutter-debug) use displayType="TOOL_WINDOW".
   • When a TOOL_WINDOW notification is shown, IntelliJ's ToolWindowManager creates and displays a Balloon anchored to the tool window tab or stripe button (e.g. Run or Debug).
2. Why Notification.expire() doesn't hide Tool Window Balloons:
   • Notification.expire() updates the status of the Notification object (marking it expired and removing it from notifications models).
   • However, for TOOL_WINDOW-type notifications, IntelliJ does not link the underlying Balloon instance to the Notification object. As a result, calling Notification.expire() alone leaves the visual Balloon visible on screen.

Gemini suggests adding a hide function for the balloons:

    private void hideToolWindowBalloons() {
      if (myProject.isDisposed()) return;
      try {
        final ToolWindowManager toolWindowManager = ToolWindowManager.getInstance(myProject);
        if (toolWindowManager != null) {
          for (String toolWindowId : toolWindowIdsToNotificationGroupIds.keySet()) {
            final Balloon balloon = toolWindowManager.getToolWindowBalloon(toolWindowId);
            if (balloon != null) {
              balloon.hide();
            }
          }
        }
      } catch (Throwable ignored) {
      }
    }

So does this not happen on your machine? I wonder if you are getting a type of balloon that is different from tool window balloons?