SUMMARY sometimes the ews resource fails with the authentication and I see the following debug output: org.kde.pim.ews.client.request: Starting SyncFolderHierarchy request (folder: EwsId(Distinguished: msgfolderroot), state: 1sgz95w org.kde.pim.ews.client.proto: data KIO::TransferJob(0x150d230) "" org.kde.pim.ews.client.proto: response dumped to "/tmp/akonadi-ews-qzRmyGa/ews_xmldump_DyEEOSp.xml" org.kde.pim.ews.client: Failed to process EWS request - HTTP code 401 org.kde.pim.ews: requestAuthFailed - going offline org.kde.pim.ews.client: Starting OAuth2 authentication org.kde.pim.ews.client: Authentication succeeded The result is still the resource being offline, despite the success in authentication. It should go online again (or not offline in the first place). SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20191025 KDE Plasma Version: 5.17.0 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 Kernel Version: 5.3.7-1-default OS Type: 64-bit
What happens here is that most likely the OAuth access token expired, which is normal after after a few hours. This caused the EWS request to fail and call for reauthentication. Since the refresh token was valid, authentication succeeded quickly and the resource is in theory back to life. The reason for the offline state is the nature of the state machine inside of the resource. When a request is processed, it has to be completed without delay to the Akonadi server. OAuth authentication on the other hand involves sending more requests to the authentication server, which would block for an unknown amount of time. Time, which the EWS resource cannot wait. Therefore upon an authentication failure the resource is immediately set to a temporary offline state. The temporary nature means that Akonadi will automatically keep trying to bring the resource back online after a short time (initially 60s, then every 300s). So if you would wait a bit longer the resource would come back online automatically. I know this behaviour is not optimal as in the described case the authentication phase takes a split second and it would probably be possible to avoid the offline state, but this would require some major architectural changes. I have actually been noticing this problem and started working on a fix (or an optimisation), which shortens the retry time after the offline state has been reached (initially 15s, gradually increasing up to 300s). I am also testing the option to explicitly bring the resource online after an authentication success. Initial attempts have resulted in some strange behaviour, which means that I will need to test this more in order to assure that it works reliably.
I assume you could call ResourceBase::doSetOnline(true); when the re-auth succeeds. Another thing I seem to encounter: after the re-auth and the resource being offline, it does no longer react to a manual "check for email" - even if the resource is no longer offline. All I can do in that case is to kill and restart it.