AvengeMedia / AvengeMedia/dms-plugins

[Phone Connect] Avoid stale KDE Connect notifications path after reconnect/suspend

Open
#82 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.