An unreachable appstore stops the API from returning a reply

[j-ed]

Expected behavior

The external monitor API should always return a reply. If some information, like e.g. the number of available app updates couldn't be evaluated, it should jump over this information instead of aborting its function at all.

Current behavior

The external monitor API, which by default also shows information about available app updates, doesn't return a reply at all if the app store is unreachable, for whatever reason.

Steps to reproduce

1. The app store is temporarily unreachable

2. Execute the API call, like e.g.

   curl -s -m 5 -k --netrc https://<nextcloud-fqdn>/ocs/v2.php/apps/serverinfo/api/v1/info
   

   => The request will most likely not return any output.

3. Check the Nextcloud log file for information about the request.

4. You will most likely find an entry with the following content:

   {
     "reqId": "JKOFfevzZHTTOKCGEFqJ7",
     "level": 1,
     "time": "2019-02-22 13:08:47+01:00",
     "remoteAddr": "<nc-server-ip>",
     "user": "<nc-user>",
     "app": "appstoreFetcher",
     "method": "GET",
     "url": "/ocs/v2.php/apps/serverinfo/api/v1/info",
     "message": {
       "Exception": "GuzzleHttp\\Exception\\ConnectException",
       "Message": "cURL error 28: Connection timed out after 10004 milliseconds (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)",
       "Code": 0,
   

   . ^^^ the connection timed out! ^^^

       "Trace": [
         {
           "file": "<path-to-nc-root>/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php",
           "line": 149,
           "function": "createRejection",
           "class": "GuzzleHttp\\Handler\\CurlFactory",
           "type": "::",
           "args": [
             {
               "sink": {
                 "__class__": "GuzzleHttp\\Psr7\\Stream"
               },
               "headers": [],
               "response": null,
               "request": {
                 "__class__": "GuzzleHttp\\Psr7\\Request"
               },
   
         ...
   
         {
           "file": "<path-to-nc-root>/nextcloud/ocs/v1.php",
           "line": 82,
           "function": "match",
           "class": "OC\\Route\\Router",
           "type": "->",
           "args": [
             "/ocsapp/apps/serverinfo/api/v1/info"
           ]
         },
         {
           "file": "<path-to-nc-root>/nextcloud/ocs/v2.php",
           "line": 24,
           "args": [
             "<path-to-nc-root>/nextcloud/ocs/v1.php"
           ],
           "function": "require_once"
         }
       ],
       "File": "<path-to-nc-root>/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php",
       "Line": 185,
       "CustomMessage": "Could not connect to appstore"
   

   . ^^^ the appstore was unreachable! ^^^

     },
     "userAgent": "curl/7.63.0",
     "version": "15.0.4.0"
   }
   
   

Environment

Server Configuration

OS: Linux 3.16.62
Web server: Apache2 2.4.37
Database: MariaDB 10.2.21
PHP version: 7.2.14
Nextcloud version: 15.0.4
Serverinfo app version: 1.5.0

Client Configuration

Browser: Mozilla Firefox 65.0.1
Operating system: Windows 10

[j-ed]

I just ran into the same problem again with Nextcloud 19.0.4 because the app store is currently (10.10.2020 17:50h) unavailable again. I thought this problem would have already been solved, but I was wrong. If you monitor your server status using the given API access, everything will turn "RED", although only the app store is unreachable 😢

[VimS]

I just Updated from 19.0.1 to 20.0.0.9 (running via docker-compsose).
Can't update Apps because https://apps.nextcloud.com/ is unreachable and systeminfo is running into a timeout.

[lrdshaper]

Same problem as @j-ed here. I use Nagios to monitor my nextcloud instances via the API and it has been flapping for 3days. I don't have a problem with app store or the upgrade servers being temporarily down/slow as I usually delay upgrades by a few weeks anyway but the API not working everytime the appstore goes down is a little frustrating.

[GAS85]

Have "holes" in my statistic because of that 😞

[joshtrichards]

I don't even think we should be polling the appstore during every poll of the serverinfo endpoint at all. Besides timeouts this is just completely unnecessary overhead for servers/network/appstore. There's little reason to check this more than once or twice a day (maybe once an hour I guess).

One option - that only addresses the timeouts but doesn't eliminate the constant polling - would be to add a means to override the hardcoded timeouts in the appstorefetcher.

A better option: There's already a background job that handles high overhead storage stats collection. We could move the appstore polling to a dedicated job for keeping the data about available app updates fresh enough for the endpoint.

Another option might be tapping into the existing job data from the updatenotifications app (which has it's own background job).

I can think of a few hacks too, but they're all ugly.

A quick fix might be to only call isUpdateAvailable() if the hour is divisible by 12 or something (not perfect but would cut down on the opportunities for the timeouts to occur and the large data gaps). :-)

[joshtrichards]

Recently merged #518 indirectly helps with this by removing the app check from being the default behavior.

[nogweii]

I think you meant #526, which was released with NC 28. Which means that this ticket can be closed now?