Bug 511499

Seems the setting/timestamp was migrated to $XDG_STATE_HOME/discovernotifierstaterc

Current value is last Monday (2025-10-27) but I did not get any visual cue when the 6.5.1 package became available.
Update interval is set to "daily"

Is it crashing on launch, maybe? I'm seeing that myself in Bug 511602.

For me it seems to run stably since I restarted it manually with systemctl

kevin@hephaistos ~ % systemctl --user status app-org.kde.discover.notifier@autostart.service
● app-org.kde.discover.notifier@autostart.service - Discover
     Loaded: loaded (/etc/xdg/autostart/org.kde.discover.notifier.desktop; generated)
     Active: active (running) since Sun 2025-11-02 10:18:09 CET; 1 day 22h ago
       Docs: man:systemd-xdg-autostart-generator(8)
    Process: 12402 ExecCondition=/usr/lib/systemd/systemd-xdg-autostart-condition KDE  (code=exited, status=0/SUCCESS)
   Main PID: 12404 (DiscoverNotifie)
      Tasks: 14 (limit: 76884)
     Memory: 28.6M (peak: 29.9M)
        CPU: 4.124s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.discover.notifier@autostart.service
             └─12404 /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier --check-delay 20

I've manually checked with Discover's main app to see if there are any updates but currently there are none.
So I don't know yet if the removal of the (old?) config file + restart changed anything

The icon has now appeared.
Clicking the icon launches Discover but it gets stuck in Fetching updates (stuck as in doesn't complete in ~10 minutes).

Will check again later.

I also have a second user account which has not seen login since update to 6.5.0 so it still has the old config and time stamp within and the new state file does not exist yet.
Might have time later today to check if it show the indicator for today's updates and how the two files get changed

I had time for a bit more testing.

Later on Wednesday I had to restart my session (actually reboot), resulting again in update icon missing.
Since the stored timestamp at this point was the same day this was probably intentional.

However, it has not reappeared on any of the days since.

I also checked with a second user account that still had the old state file.
Logging in did remove the value from the old state file (leaving it empty) and did show the icon, as well as writing a new time stamp into the new state file.

On the main account I needed to restart app-org.kde.discover.notifier@autostart.service for it to show the icon again.

My guess is that the the service does either not recheck once it has notified about updates or that it does not use the value configured for "Notification Interval" in Discover's main UI.

I have the impression that, once the notification is sent, it waits the delay set in "Notification interval", in my case 60*60*24, no matter what happens.
This is the case if I logout/login or if updates arrive in the meantime.
I solved the problem by moving the timestamp back more than a day and removing write permissions from the discovernotifierstaterc file. This way I'm alerted if updates arrive and if I log out and back in.

Is it maybe related  to 511602?

Nate linked to that earlier already but I am not seeing any crash.

According to systemctl status it has been running since the start of the session and I am pretty sure it will continue to do so until next time I logout or restart.

I just restarted it and it did notify me about the pending updates (last update on Saturday evening) and only now it shows the icon again.

Restarting it another time and the icon is gone.

I have now stopped the systemd unit and restarted it manually in a shell with debug logging enabled

QT_LOGGING_RULES=org.kde.*.debug=true /usr/lib/x86_64-linux-gnu/libexec/DiscoverNotifier --check-delay 20               :(

org.kde.plasma.discover.notifier: Not triggering, state is DiscoverNotifier::NoUpdates
org.kde.plasma.discover.notifier: refreshUnattended: not notifying about updates
org.kde.plasma.discover.notifier: updateStatusNotifier: hasUpdates false hasSecurityUpdates false
org.kde.plasma.libdiscover.backend.packagekit: using... PackageKit::Transaction(0x624d62a4c5b0) "/4697_edeadbeb"
org.kde.plasma.discover.notifier: updateStatusNotifier: hasUpdates true hasSecurityUpdates false
org.kde.plasma.discover.notifier: Not triggering, earliestNextTriggerTime is QDateTime(2025-11-11 17:37:09.827 UTC Qt::TimeZone UTC )
org.kde.plasma.discover.notifier: showUpdatesNotification: not notifying about updates
org.kde.plasma.discover.notifier: refreshUnattended: useUnattendedUpdates false isOnline true isConnectionAdequate true

So at least the problem at startup is not the missing check but the timestamp comparison.
Which is should probably not do on startup otherwise logging out and logging in again loses UI state.

Will keep this running until Wednesday when at least one interval check should have happened

from   NotifierItem.cpp
-----------------------------------------------------------------------------------------------
  case DiscoverNotifier::NormalUpdates: {
        // Only show the status notifier on next notification time
        // BUG: 466693
.......
.......
-----------------------------------------------------------------------------------------------
https://invent.kde.org/plasma/discover/-/merge_requests/886
https://bugs.kde.org/show_bug.cgi?id=466693

Updated to 6.5.2 on the weekend and got the icon earlier this week (at which time I installed some but not all updates) and again today.

Still, I wonder if the tray icon should count as "notification" (i.e. transient), IMHO it displays state.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

So is the issue fixed now? What's the current status? Sorry, I'm having a hard time following it.

It seemed to work again the week before last week but failed again last week.

I think the problem is that the logic to suppress notifications is also applied to the icon but the icon.

The notification is an event, the icon is state.

It makes sense to not trigger the event again for a given period unless the state changes significantly, e.g. new security updates available, but the state needs to visualized at its current level.

I.e. the icon is "hidden" when there are no updates but "visible" when there are any, regardless of whether they are normal or security related.

Otherwise that information (state visual) is lost when the session (or just the service) restarts.

IIRC it's intentional that the tray icon is suppressed when the notification is suppressed. Both are supposed to honor the value of the update check interval setting in System Settings > Updates.

If that's not working, then there's a bug; if it is working, then I think this is working as expected.

At the moment the icon does neither work as a notification nor as a status indicator.

If it were a notification it would be gone when clicked, I've seen the update in Discover and decided not to react to it.

If it were a status indicator it would still be there when I log out and log in again.

Right now it does neither.

Given that almost every other icon in the tray is a status indicator, I find it strange that this one should behave like a notification.
And unlike any other notification not show up as a popup and not be accessible in the notification history.

I am likely missing some important piece of information.

Created attachment 187509 [details]
Suggested behavior as a state diagram

I've attached a state diagram in an attempt to try to explain what I think should be the behavior.

We have three states and several transitions.
* Each state has an associated icon (or no icon).
* Each transition might trigger a notification or might have the notification suppressed/silenced 

I think transition T4 is the one people do not want to trigger notifications.
Maybe T5 as well.

We could even enable users to disable all notifications, like most of our other apps do.

That's accurate. But it's missing one part: the T1 and T2 transitions are supposed to respect the update check frequency in System Settings > Updates.

It isn't even supposed to *look* for updates more frequently than configured there.

There should be a frequency=always. 
This way, the status icon is always in the systray when needed.
I simulate this behavior by removing write permissions on the discovernotifierstaterc file.

(In reply to Nate Graham from comment #18)
> That's accurate. But it's missing one part: the T1 and T2 transitions are
> supposed to respect the update check frequency in System Settings > Updates.

Yes, maybe that is also intended.

Main point is that the icon needs to be updated when a new state is entered, regardless of whether the transition triggers a notification or not.

> It isn't even supposed to *look* for updates more frequently than configured
> there.

That might even get rid of the "last notification" timestamp.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Based on all the investigation and debugging so far, is it clear to you which exact circumstances/config file keys/etc cause this to happen?

Since I can't reproduce it, I think we need to nail down specific steps to reproduce to make this actionable.

The easiest way to reproduce this is to restart the service (simulating  session logout/login) once the status icon is shown.

1. Verify that the status icon is shown
2. Verify that the timestamp in `.local/state/discovernotifierstaterc` is less than your "update interval" old (in my case less than 24h)
3. systemctl --user restart app-org.kde.discover.notifier@autostart.service

Expected: Status icon indicating that there are updates
Observed: No icon

As luca pointed out in https://bugs.kde.org/show_bug.cgi?id=511499#c10 the issue seems to have been introduced by a workaround for a bug report about checks happening too often.

Given the multiple backends this is probably difficult to actually fix, so there was an attempt to hide this or mitigate the UI "noise" by remembering the last time the user was notified about updates.

However, the check is accidentally applied against the status not the notification.
I.e. the check is in `NotifierItem::shouldShowStatusNotifier()` when it should probably be in `DiscoverNotifier::notifyAboutUpdates()`, `DiscoverNotifier::showUpdatesNotification()` or `DiscoverNotifier::showDiscoverUpdates()` (these seem to be the places that deal with the actual notification, not the status/state)