Fix: Dismiss "update available" notifications after package installation

[Copilot]

Context

Notifications persist after package updates complete. When auto-updates are enabled, users see "Update available" notifications for packages that were already updated, with no way to act on them except manual dismissal.

Approach

Send resolved notifications on package installation using the same correlationId as triggered notifications. The notification service matches by correlationId and dismisses the triggered notification when receiving a resolved one.

Changes:

• Added sendPackageInstallResolvedNotification() that sends Status.resolved notifications for non-core packages after successful installation
• Integrated into packageInstall() flow after sendCoreInstalledResolvedNotification()
• Uses matching correlationId: "dappmanager-update-pkg" to pair with update-available notifications from sendUpdateNotification.ts

Pattern:

// Triggered when update detected
status: Status.triggered,
correlationId: "dappmanager-update-pkg"

// Resolved after installation (new)
status: Status.resolved,
correlationId: "dappmanager-update-pkg"

Core packages excluded (handled separately by sendCoreInstalledResolvedNotification). Error handling prevents notification failures from breaking installations.

Test instructions

1. Enable auto-updates for a test package
2. Trigger an update (or wait for one to be detected)
3. Verify "Update available" notification appears
4. Wait for auto-update to complete (or manually update)
5. Verify original notification is dismissed and replaced with "installed successfully" notification

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• binaries.soliditylang.org
  • Triggering command: /usr/local/bin/node /usr/local/bin/node ./build/cli.bundled.js obtain --solc=0.5.16 /home/REDACTED/.cache/node-gyp/20.19.6/deps/zlib -I /home/REDACTED/.cache/node-gyp/20.19.6/deps/v8/include -I ../deps/cpu_features/include -I ../deps/cpu_features/include/internal --64 (dns block)
• ethereum.github.io
  • Triggering command: /usr/local/bin/node /usr/local/bin/node ./build/cli.bundled.js obtain --solc=0.5.16 /home/REDACTED/.cache/node-gyp/20.19.6/deps/zlib -I /home/REDACTED/.cache/node-gyp/20.19.6/deps/v8/include -I ../deps/cpu_features/include -I ../deps/cpu_features/include/internal --64 (dns block)
• relay.trufflesuite.com
  • Triggering command: /usr/local/bin/node /usr/local/bin/node ./build/cli.bundled.js obtain --solc=0.5.16 /home/REDACTED/.cache/node-gyp/20.19.6/deps/zlib -I /home/REDACTED/.cache/node-gyp/20.19.6/deps/v8/include -I ../deps/cpu_features/include -I ../deps/cpu_features/include/internal --64 (dns block)
• solc-bin.ethereum.org
  • Triggering command: /usr/local/bin/node /usr/local/bin/node ./build/cli.bundled.js obtain --solc=0.5.16 /home/REDACTED/.cache/node-gyp/20.19.6/deps/zlib -I /home/REDACTED/.cache/node-gyp/20.19.6/deps/v8/include -I ../deps/cpu_features/include -I ../deps/cpu_features/include/internal --64 (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Notifications are not synced to the state of the dappnode.</issue_title>
<issue_description>

Describe the bug

Currently notifications are triggered when there's an update, or a condition for notification has been met (i.e.: proposed a block).

Some of these notifications are meant to signal that a potential change of state is ready - an update of a package, for example.

Nevertheless, when the state is changed (i.e.: the package is updated), the notification is not dismissed.

This is particularly annoying when autoupdates are activated, because the notification will trigger, the autoupdate will trigger shortly after, and by the time a user logs in, the state has changed / the package has updated, but the notification is still there.

Of course, the user cannot possibly know at first glance whether the state has changed or not - they only see a notification saying "The update is available", but maybe the update isn't available anymore because it has been updated. The user clicks on the notification and is directed to a page where it cannot take any action.

Moreover, the notification doesn't then disappear either, it has to be manually dismissed by pressing the X.

Expected behavior

1. The notification should disappear when the state has changed.
2. If the user needs to be informed that there has been an update, maybe a new notification saying: "This package has been auto-updated", but for sure 1. should happen - meaning the notification that the update is available should disappear instead.

• Package version:
• OS:
• Browser

Additional context

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Notifications are not synced to the state of the dappnode. #2323

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.