AvengeMedia / AvengeMedia/dms-plugins
[Phone Connect] Avoid stale KDE Connect notifications path after reconnect/suspend
- Dominant language
- QML
- Stars
- 84
- Forks
- 25
- Avg merge
- 17h 11m
- Merged PRs (30d)
- 1
Description
## Problem
Phone Connect currently assumes KDE Connect always exposes a device notifications DBus path at:
`/modules/kdeconnect/devices//notifications`
On my system, after suspend/reconnect or after Bluetooth reconnects, that path can become stale or unavailable. When Phone Connect keeps querying it, DMS logs repeated errors such as:
`No such object path '/modules/kdeconnect/devices//notifications'`
## What I observed
- KDE Connect itself is still reachable and usable.
- Battery / MPRIS / ping / pairing continue to work.
- The notifications query is the noisy part.
- The issue is especially visible after reconnecting the phone or resuming from suspend.
## Steps to reproduce
1. Pair a phone with KDE Connect.
2. Suspend/resume the desktop or disconnect/reconnect Bluetooth.
3. Open Phone Connect in DMS.
4. DMS repeatedly logs errors while trying to read the notifications path.
## Expected behavior
If notifications are unavailable for a device, Phone Connect should:
- treat notifications as optional,
- stop retrying the stale path for that device,
- and continue showing the rest of the device state normally.
## Actual behavior
Phone Connect keeps trying to read the stale notifications path and spams the logs.
## Possible fix
A small backend guard would help:
- cache a per-device "notifications unavailable" state after a failed lookup,
- avoid re-querying the notifications path until the device refreshes cleanly,
- optionally keep the notification badge at 0 or N/A when the feature is unavailable.
## Workaround used locally
I disabled the notifications polling path in KDE Connect backend code so the rest of Phone Connect stays quiet and functional.
Contributor guide
Research direction
Start at the Phone Connect KDE Connect backend notification polling path and reproduce the stale notifications DBus path after suspend/resume or Bluetooth reconnect. Done means unavailable notifications stop being queried for that device, log spam stops, and battery, MPRIS, ping, pairing, and other device state continue working.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100