Bug 490742 - KMail sometimes fails to mark opened emails as read
Summary: KMail sometimes fails to mark opened emails as read
Status: RESOLVED UPSTREAM
Alias: None
Product: kmail2
Classification: Applications
Component: UI (other bugs)
Version First Reported In: 6.1.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Andreas Hartmetz
URL:
Keywords:
: 385225 414806 417242 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-07-24 06:02 UTC by Holmes
Modified: 2025-12-06 16:38 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Holmes 2024-07-24 06:02:16 UTC
SUMMARY
When opening an email, KMail sometimes fails to mark it as read. The email will remain unread forever, no matter how many times you open it. Only way to mark it as read is to manually mark it as read.

STEPS TO REPRODUCE
1. Open KMail
2. Open an email that has not been read yet

OBSERVED RESULT
KMail does not mark the mail as read when you open it

EXPECTED RESULT
KMail should mark the mail as read when you open it

Operating System: Arch Linux 
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Graphics Platform: Wayland
Comment 1 Holmes 2025-09-21 19:14:35 UTC
Bumping this to make sure this doesn't get forgotten for decades.
Comment 2 Andreas Hartmetz 2025-10-30 12:37:02 UTC
Assigning to me. There are many things that I see not updating: moving messages, read status and others. It works after restarting KMail but not Akonadi - even previously made changes appear after the restart. So it seems like changes make it from KMail to Akonadi (and probably IMAP server, in my case), but not back to KMail. Strange. At least it seems like a single bug with a single fix to fix many kinds of updates.

Both the breakage and it going away after a KMail restart seem to reproduce every time for me, there is no randomness.
Comment 3 Andreas Hartmetz 2025-11-23 16:07:23 UTC
I have root-caused this to a Qt (arguably) bug, and I have a fix, too: https://codereview.qt-project.org/c/qt/qtbase/+/693140
If that one doesn't get accepted or takes too long to roll out, workarounds are possible now that the problem is understood.
Comment 4 Andreas Hartmetz 2025-11-30 15:17:01 UTC
Git commit 27c77220ea19688ff4f204df1e3092f69f183f03 by Andreas Hartmetz.
Committed on 30/11/2025 at 14:16.
Pushed by ahartmetz into branch 'master'.

Work around QLocalSocket::waitForBytesWritten() problem on Unix

It can emit readyRead(), and handlers of that signal may end up
writing out data, which may result in waitForBytesWritten() itself
not being able to write anymore and returning false (even though
data was written).
So far, the problem has only been observed to happen in
NotificationSubscriber, specifically in bogus connection timeouts
breaking message "read" status  updates. They should propagate
client -> server -> client, which broke at server -> client.

This should be updated and eventually removed as fixed Qt versions
become available.

M  +2    -0    src/server/CMakeLists.txt
A  +28   -0    src/server/localsocket.cpp     [License: LGPL(v2.0+)]
A  +46   -0    src/server/localsocket_p.h     [License: LGPL(v2.0+)]
M  +2    -2    src/server/notificationsubscriber.cpp
M  +2    -3    src/server/notificationsubscriber.h

https://invent.kde.org/pim/akonadi/-/commit/27c77220ea19688ff4f204df1e3092f69f183f03
Comment 5 Andreas Hartmetz 2025-12-06 16:31:25 UTC
*** Bug 417242 has been marked as a duplicate of this bug. ***
Comment 6 Andreas Hartmetz 2025-12-06 16:38:04 UTC
*** Bug 385225 has been marked as a duplicate of this bug. ***
Comment 7 Andreas Hartmetz 2025-12-06 16:38:24 UTC
*** Bug 414806 has been marked as a duplicate of this bug. ***