https://bugs.kde.org/show_bug.cgi?id=525082
Bug ID: 525082
Summary: IMAP resource stops syncing silently after failed
XOAUTH2 token refresh; status keeps reporting "Ready"
Classification: Frameworks and Libraries
Product: Akonadi
Version First 6.8.0
Reported In:
Platform: Neon
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: IMAP resource
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
SUMMARY
After a failed OAuth2 (XOAUTH2) token refresh against an Office 365 / Exchange
Online IMAP account, akonadi_imap_resource stopped syncing entirely for several
days, while Akonadi kept reporting the resource's D-Bus status as "Ready" /
"Connection established" (isOnline=true, status=0). I didn't see any error
anywhere in KMail's UI, so I didn't see the outage until it became obvious I
was missing emails and I checked the logs.
ENVIRONMENT
- kmail2 / akonadi 6.8.0 (26.08.1), KDE neon User Edition, Wayland
- IMAP account: Microsoft Exchange Online (outlook.office365.com), STARTTLS
port 143, Authentication: XOAuth (XOAUTH2)
- No KAccounts/signond involved on my system; OAuth2 is handled internally by
kdepim-runtime
TIMELINE (from journalctl --user)
- Last successfully synced message: 2026-08-27 ~14:38
- 2026-08-28 18:20:29 - akonadi_imap_resource: "Failed to parse token response:
''" (empty response while refreshing the OAuth2 token)
- A few more automatic token-refresh attempts on 2026-08-29 and 2026-08-31
07:56, then:
- 2026-08-31 07:56:27 - akonadi_imap_resource: "Connection to server lost
QAbstractSocket::UnknownSocketError"
- From that point on: complete silence in the logs for this resource - no
further token requests, no reconnection attempts - for more than 24h, until
investigated on 2026-09-01.
- Throughout the whole period, org.freedesktop.Akonadi.Agent.Status on the
resource's D-Bus object kept returning statusMessage="Ready" (or later
"Connection established"), status=0, isOnline=true.
- Network connectivity, DNS and system clock were all verified fine at
diagnosis time; a direct TCP connection to the IMAP server succeeded
immediately, ruling out a network-side cause.
ADDITIONAL OBSERVATION (possibly a separate bug)
The "Restart" action in "Configure KMail" -> Accounts -> Receiving did not
actually kill/respawn the underlying akonadi_imap_resource process: the same
PID (running continuously since 2026-08-27) was still alive and stuck
afterward. Only `akonadictl restart` (which does kill and respawn the agent)
actually recovered the account - after that the resource re-authenticated via
XOAUTH2 successfully and immediately fetched ~5 days of backlog (69 items)
within seconds.
EXPECTED BEHAVIOR
- A failed OAuth2 token refresh (especially a response that can't even be
parsed) should put the resource into a visible error state via Agent::Status
(Broken + a message), not leave it silently reporting "Ready"/"Connection
established".
- The "Restart" action available from the account list in Configure KMail
should guarantee the underlying resource process is actually terminated and
respawned, not just prompted to reconnect on its existing (possibly stuck)
instance.
REPRODUCIBILITY
Not reliably reproducible on demand - the trigger was a one-off OAuth2
token-refresh failure on Microsoft's side. However the resulting failure mode
(silent status desync after a broken reconnect loop) looks structural rather
than accidental: similar reports exist for Gmail OAuth2 ("Gmail authentication
expires after some time", bug 379131; "Akonadi IMAP resource not syncing after
system startup/resume, requires Akonadi to be restarted", bug 258479), so this
may not be Office365-specific.
Happy to attach the full anonymized journalctl excerpt if useful.
--
You are receiving this mail because:
You are watching all bug changes.
