SUMMARY Today I sent two messages (very long ones). Since they usually take a while to appear on screen I thought noting when I didn't see them; after checking my phone now though it seems that the connection got lost and both messages "just dissapeared". As of my knowledge, there was no warning about a lost connection or possibly lost messages. STEPS TO REPRODUCE 1. Open KDE Connect SMS when connection is established 2. Turn on airplane mode (or disable WiFi) on the phone 3. Send SMSs. OBSERVED RESULT The SMSs just silently disappear. EXPECTED RESULT There should be atleast an error message and the app should stop you from sending (and thereby deleting) a typed text. Better would be a classic "Resend when available" behaviour or atleast (like other messengers) storing the message in the chat log, marked as "Unable to send" (Icon or error message), so the user can resend manually. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux ra1n-desktop-manjaro 6.6.0-2-MANJARO #1 SMP PREEMPT_DYNAMIC Tue Oct 31 03:10:07 UTC 2023 x86_64 GNU/Linux (available in About System) KDE Plasma Version: KDE Frameworks Version: - kded5: 5.111.0-1 - (for other KDE packages please ask, as on Manjaro it's difficult for me to track which are important) Qt Version: - qt5-base: 5.15.11+kde+r138-1 ADDITIONAL INFORMATION - I know on Manjaro with XFCE the app probably doesn't run as smoothly, or you even don't support the environment, but that sounds like an issue which could be resolved at a basic layer and could be relevant to Plasma users as well - not a duplicate of #425638 - the cause of messages not sent is clear: no connection. However the unsent messages should never be allowed to disappear and probably always stored in the chatlog - even if there is an error while sending. I marked severity as "critical" since it caused data loss and is easily reproducible *on my system*. If that is incorrect, go ahead and change it, but please consider just adding some simple mechanism to prevent that data loss in any case.
Thanks for reporting this. Marking as confirmed because this is something which definitely can happen. I thought I had already written a bug report for this, but apparently not. I have adjusted the priority to "HI" and the severity to "major" -- I agree this is very annoying, and dataloss makes this a more-serious case, but I would like to reserve "critical" for things which are really a disaster, like data being compromised by 3rd parties, etc. This is a tough case to handle, given the way the app was designed. If the connection is lost, then the connection is lost. Since the model is that Android is the source of truth, and since that has been lost, recovering from this situation is outside of the original design. The desktop app could perhaps cache messages in some way (even if it were as simple as allowing the user to copy-paste them out of the GUI).
For me, one of the following would greatly improve usability (while hopefully don't take much time and resources to implement): - Disabling the message input and/or displaying a very visible warning. - Outright close the messenger (while optionally saving what is currently entered in the chat box. Maybe some of that would be in the current scope of dev priorities. (I just rechecked by Enable Airplane mode->send messages on PC-> disable Airplane mode, that no warning whatsoever is displayed on my PC. I don't know if a keepalive is used but maybe it should be lower.)
(In reply to unsubtleness_wastery from comment #2) > (I just rechecked by Enable Airplane mode->send messages on PC-> disable > Airplane mode, that no warning whatsoever is displayed on my PC. I don't > know if a keepalive is used but maybe it should be lower.) There is a keepalive in KDE Connect as a whole. IIRC, it's just the timeout of the TCP connection, which nominally you could configure, but it would then apply to everything on your system. > - Disabling the message input and/or displaying a very visible warning. Once the connection is detected as lost, this is what happens.