You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tl;dr: Do not issue any connectivity related errors within the first 60s of system boot time.
The problem
On system start-up, the establishment of on internet connection may be delayed due to a number of factors. Chief among them being VPNs, especially in a corporate environment.
The Nextcloud Desktop Client is fairly lean and starts up rather quickly, before the proper authentication is completed to connect my system via a VPN to the outside. As a result, every time I boot up the computer, I am greeted with Nextcloud complaining about a missing connection. After 10 seconds or so Nextcloud successfully connects to the Nextcloud server, with the error still displayed, as it is a system message.
Nextcloud Desktop Client Version 3.6.6 (Windows)
A bunch of file-sync programs show this behavior, another one being https://github.com/duplicati/duplicati. It is a fairly jarring experience, being greeted each startup with connection errors from different sync solutions, even though 20 secs later everything is fine.
The solution
Of course, this is nothing that cannot be solved with a one-liner sleep() command in a shell script, however, I think this could be solved more elegantly: Getting time-since-boot is fairly simple with OS specific APIs. Eg. doc entry for Windows. With that time, errors could be prevented from being issued. The logical next step would be to check time since logon, the number that actually more closely represents how a user interacts with a PC and base the 60s delay off of that.
required fail-safes
Especially on system boot is where NTP updates happen, so there is the danger of checking time and getting stuck in this no error state for a very long time due to sudden time zone shifts. An internal 60s timer should be started additionally, in case the time since boot calculation returns a bad result.
The text was updated successfully, but these errors were encountered:
joshtrichards
changed the title
[Feature request] Delay errors about missing connectivity after start-up
Delay errors about missing connectivity after start-up
Nov 26, 2023
I have this same issue, but without the VPN complexity. When waking my laptop, I receive the same error. Somehow before my WiFi connection is even set back up, NextCloud has already popped this error.
Feature description
tl;dr: Do not issue any connectivity related errors within the first 60s of system boot time.
The problem
On system start-up, the establishment of on internet connection may be delayed due to a number of factors. Chief among them being VPNs, especially in a corporate environment.
The Nextcloud Desktop Client is fairly lean and starts up rather quickly, before the proper authentication is completed to connect my system via a VPN to the outside. As a result, every time I boot up the computer, I am greeted with Nextcloud complaining about a missing connection. After 10 seconds or so Nextcloud successfully connects to the Nextcloud server, with the error still displayed, as it is a system message.
A bunch of file-sync programs show this behavior, another one being https://github.com/duplicati/duplicati. It is a fairly jarring experience, being greeted each startup with connection errors from different sync solutions, even though 20 secs later everything is fine.
The solution
Of course, this is nothing that cannot be solved with a one-liner
sleep()
command in a shell script, however, I think this could be solved more elegantly: Getting time-since-boot is fairly simple with OS specific APIs. Eg. doc entry for Windows. With that time, errors could be prevented from being issued. The logical next step would be to check time since logon, the number that actually more closely represents how a user interacts with a PC and base the 60s delay off of that.required fail-safes
Especially on system boot is where NTP updates happen, so there is the danger of checking time and getting stuck in this no error state for a very long time due to sudden time zone shifts. An internal 60s timer should be started additionally, in case the time since boot calculation returns a bad result.
The text was updated successfully, but these errors were encountered: