https://bugs.kde.org/show_bug.cgi?id=517659
Bug ID: 517659
Summary: SMS conversation stops updating after device WiFi
reconnect
Classification: Applications
Product: kdeconnect
Version First unspecified
Reported In:
Platform: Ubuntu
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: messaging-application
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Summary: SMS conversation stops updating after device WiFi reconnect
Steps to reproduce:
Open the SMS app, select a conversation
Send a message and confirm it appears in the chat
Turn off WiFi on the phone, wait about 10 seconds, turn it back on
Wait for KDE Connect to reconnect
Send another message
Expected behavior: The sent message appears in the conversation within a few
seconds.
Actual behavior: The message is delivered to the phone but never appears in the
desktop conversation. This continues for every subsequent send -- the messages
all reach the phone, but nothing updates on the desktop. The problem does not
resolve on its own. Switching to a different conversation and back fixes it
immediately.
https://youtu.be/kwrl5OPcPyw
Analysis:
After WiFi reconnection, the phone opens a new TCP link to the daemon. The old
link has not timed out yet (TCP keepalive), so the daemon sees multiple links
and does not reload plugins. The SmsPlugin and its D-Bus adaptor remain valid
throughout -- there is no daemon-side breakage.
The issue is on the phone side. The Android app stops pushing SMS echo
notifications after the reconnect. I confirmed this with D-Bus monitoring:
after the reconnect, zero receivePacket calls arrive at the daemon for message
echoes, even though the outbound replyToConversation calls go through fine and
the messages reach the phone.
Switching conversations works because ConversationListModel::refresh() calls
requestAllConversationThreads(), which sends an explicit request to the phone.
The phone responds to this correctly, and it also seems to kick the phone's
echo push back into working order.
Note that the sending area is correctly disabled once the daemon detects a
disconnect, but TCP keepalive timeouts mean this detection can take several
minutes. The bug manifests during this window when the UI appears fully
functional.
Proposed fix:
Add an echo watchdog timer to ConversationModel. After each send, start a
3-second single-shot timer. If the echo arrives (conversationUpdated signal),
cancel the timer. If it does not, the timer fires and calls
requestAllConversationThreads() to actively sync with the phone. This retrieves
any missed messages and restores the echo push. No daemon changes needed.
This is a client-side workaround for a phone-side problem. The SMS app
currently has no connection health monitoring, no message delivery status
model, and no error path for failed sends. Longer term, addressing those gaps
would make workarounds like this unnecessary. But in the meantime, the watchdog
is a low-risk fix that solves the immediate problem without touching the daemon
or the protocol.
This fix also complements a separate fix for BUG 476747, which defers clearing
the input field until the message echo is received. Without the watchdog, that
fix would leave the input stuck after a reconnect since the echo never arrives.
I have a working patch and will submit an MR.
Environment:
KDE Connect desktop: 26.07.70 (git master, 98c4fef81)
KDE Connect Android: 1.35.5
Phone: Pixel 10 Pro XL (Android)
Desktop: Ubuntu 24.04, kernel 6.17.0-19-generic, x86_64
Qt 6.9.3, KF6
--
You are receiving this mail because:
You are watching all bug changes.
