[matt-edmondson]

Found while starting the NoSleep migration onto ktsu.TrayApp 1.1.0 — NoSleep is the first real tool through this path, and it hits the bug.

The bug

Restoring a remembered toggle calls the tool's setter:

foreach (TrayToggleItem toggle in app.Toggles)
{
    if (toggle.PreferenceKey is null || store.Get(toggle.PreferenceKey) is not bool remembered)
    {
        continue;
    }

    toggle.Set(remembered);   // <- bare
}

That setter can refuse for exactly the reason a click can. Restoring "keep awake: on" asks the tool to take an inhibitor, and the machine may have none to give — NoSleep's KeepAwakeController.Enable() throws SleepBlockException or PlatformNotSupportedException in that case.

LoadPreferences runs from RunAsync before the menu is built, so there is nowhere for the refusal to land, and nothing catches it. The exception escapes RunAsync and ends the process before the tray ever appears.

That is the one failure mode this library exists to prevent, in the library's own startup path — and it is a regression against the tool it is meant to replace: NoSleep today wraps its startup Enable() in catch (Exception ex) when (ex is SleepBlockException or PlatformNotSupportedException), prints the message, and still shows the tray so the user can retry once whatever was missing is installed. A tool ported onto 1.1.0 as-is would lose that.

The fix

Catch per toggle, report to standard error, and hand the first message back for the menu's status line via a new internal TrayMenu.SeedError, which the next successful action clears like any other failure. Two consequences worth stating:

• The toggles after the one that refused are still restored. One unavailable inhibitor should not also forget the user's other settings.
• The tray still comes up, saying why. Same destination a click's refusal reaches, because there is nowhere better for it to go.

RunTray takes the message and seeds the menu before the host starts, so the status line is already correct on the first paint rather than after the first refresh.

Verified

• Unit tests, 103 passing (1 inconclusive by platform). New: a restore where the first toggle's setter throws — LoadPreferences returns the message instead of propagating, and the second toggle is still restored; a clean restore returns null; and a seeded error shows as Demo failed: … in the status line and clears on the next successful action.
• The real restore path, through a tray. With a status-notifier host on a session bus under xvfb, across two processes:

########## run 1: click Running off ##########
--- before ---
  id=1 label='running for 00:00:00' checked=None enabled=False
  id=3 label='Running' checked=1 enabled=True
--- after ---
  id=6 label='idle' checked=None enabled=False
  id=8 label='Running' checked=0 enabled=True
persisted: {"Toggles":{"running":false}}
########## run 2: the remembered OFF must be restored ##########
--- before ---
  id=1 label='idle' checked=None enabled=False
  id=3 label='Running' checked=0 enabled=True
run 2 exit=0

A fresh process comes up already unchecked with the status line reading idle. The restore path was previously only unit-tested; this is it working through a real com.canonical.dbusmenu menu.

Tagged [patch]. As before, this is left for you to merge — it publishes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C5iSfFNhum18dnc794cVvy

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud