[Akonadi] [Bug 502959] New: Akonadi should try harder to connect to *DAV servers

[Hadrien G.]

https://bugs.kde.org/show_bug.cgi?id=502959

            Bug ID: 502959
           Summary: Akonadi should try harder to connect to *DAV servers
    Classification: Frameworks and Libraries
           Product: Akonadi
           Version: 6.3.3
          Platform: Arch Linux
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: DAV Resource
          Assignee: kdepim-bugs at kde.org
          Reporter: knights_of_ni at gmx.com
                CC: carl at carlschwan.eu
  Target Milestone: ---

SUMMARY
I have noticed on my wired boxes with a simple systemd-networkd setup that if
the Akonadi service does not manage to connect to some *DAV servers on startup,
it will flag the associated resources as offline and never try to connect to
them again. Thus e.g. CalDAV calendar sync will be lost for the entire user
session unless manually restarted using something like the "akonadictl restart"
CLI command or the KOrganizer account configuration dialog's "Restart" buttons.

While I can work around this problem for my own purposes, I believe that in a
world where intermittent Internet connectivity is very common (think laptops),
only trying to connect to a service once before giving up like this is wrong.
IMO Akonadi should do at least one of the following things instead :

- When a network interface becomes up or switches to a different configuration,
retry previous failed *DAV sync
    * This notification-based approach minimizes the delay between Internet
availability and CalDAV sync service restoration, but it relies on the
availability of reliable network status change notifications, which may not be
available due to OS limitations and other reasons described below.
- When a *DAV sync fails, try it again after some time, possibly putting the
user in control of the associated polling rate
    * This polling-based approach sounds easier to implement and works better
with flaky CalDAV servers, as well as some common flavors of flaky Internet
connexions like mobile phones acting as a wifi hotspot where the hotspot is
stable but the cellular connexion is not. However, in better network
conditions, such polling will result in a significant delay between Internet
availability and sync availability. Attempting to reduce this delay by reducing
the polling interval will increase background resource consumption and make
laptop batteries sad.

STEPS TO REPRODUCE
1. Set up a CalDAV connection in KOrganizer or Merkuro
2. Restart system in a network configuration where the CalDAV server is
unreachable
3. Start any app that relies on Akonadi (this may be automatic if e.g. the
clock plasmoid is set up to show CalDAV events)
4. Connect system to the internet

OBSERVED RESULT
After the initial sync failure, CalDAV sync will never be resumed. Akonadi will
keep the CalDAV resource in a failed state for the entire user session unless
the sync is manually restarted.

EXPECTED RESULT
Akonadi should eventually retry to connect to the CalDAV server. It might also
be a good idea to make failures a bit noisier as the "(Disconnected)" label is
not shown in some apps like the plasmoid applet and it is relatively easy to
visually miss even in the apps that do have it because it is not in a UI
location that one normally needs to look at.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.9.0
Kernel Version: 6.14.2-arch1-1 (64-bit)

ADDITIONAL INFORMATION
I observed this problem on several other Arch-based machines so it does not
seem hardware-specific.

-- 
You are receiving this mail because:
You are the assignee for the bug.