update:check and app:update --all don't match

[joekerna]

A lot of times occ update:check returns

Everything up to date

and when I still run occ app:update --all afterwards I get do get updates.

The entire shell looks like this:

user@server:~$ occ update:check
Everything up to date
user@server:~$ occ app:update --all
contacts new version available: 3.5.1
contacts updated
facerecognition new version available: 0.8.0
facerecognition updated

or later the same day:

user@server:/opt$ occ update:check
Everything up to date
user@server:/opt$ occ app:update --all
facerecognition new version available: 0.8.1
facerecognition updated

[MorrisJobke]

cc @nickvergessen

[joekerna]

user@server:~$ occ update:check
Everything up to date
user@server:~$ occ app:update --all
calendar new version available: 2.2.0
calendar updated

[nickvergessen]

Only difference I can see is:
update:check loops over:

server/apps/updatenotification/lib/Command/Check.php

Line 78 in d7c0b9c

$apps = $this->appManager->getInstalledApps();

While app:update --all loops over:

server/core/Command/App/Update.php

Line 102 in 2a054e6

$apps = \OC_App::getAllApps();

But there shouldn't be a difference unless you have apps in your server which you didn't install at all

[joekerna]

I don't understand.
Some apps were there from the beginning (like calendar) and some I've installed manually (like facerecognition).
But somehow they we all installed, right?!

[nickvergessen]

Yeah this was more technical information for other developers if someone has time to look at it.

I just debugged it on my server and for me the assumption is correct. I had 2 apps not showing up in update:check (contacts and richdocuments) but both are disabled:

$ sudo -u www-data /var/www/nextcloud/occ config:list richdocuments
{
    "apps": {
        "richdocuments": {
            "disable_certificate_verification": "yes",
            "enabled": "no",
            "installed_version": "3.7.17",
            "types": "filesystem,dav,prevent_group_restriction",
            "wopi_url": "…"
        }
    }
}
$ sudo -u www-data /var/www/nextcloud/occ config:list contacts
{
    "apps": {
        "contacts": {
            "enabled": "no",
            "installed_version": "3.5.1",
            "types": "dav"
        }
    }
}
$ sudo -u www-data /var/www/nextcloud/occ app:list
Enabled:
  - accessibility: 1.6.0
  - activity: 2.13.4
  - analytics: 3.4.1
  - calendar: 2.2.0
  - cloud_federation_api: 1.3.0
  - comments: 1.10.0
  - contactsinteraction: 1.1.0
  - cospend: 1.3.0
  - dashboard: 7.0.0
  - dav: 1.16.2
  - deck: 1.2.5
  - dropit: 0.4.0
  - event_update_notification: 1.2.0
  - federatedfilesharing: 1.10.2
  - federation: 1.10.1
  - files: 1.15.0
  - files_accesscontrol: 1.10.2
  - files_automatedtagging: 1.10.1
  - files_markdown: 2.3.3
  - files_pdfviewer: 2.0.1
  - files_rightclick: 0.17.0
  - files_sharing: 1.12.2
  - files_trashbin: 1.10.1
  - files_versions: 1.13.0
  - files_videoplayer: 1.9.0
  - firstrunwizard: 2.9.0
  - logreader: 2.5.0
  - lookup_server_connector: 1.8.0
  - mail: 1.9.3
  - nextcloud_announcements: 1.9.0
  - notifications: 2.8.0
  - oauth2: 1.8.0
  - password_policy: 1.10.1
  - photos: 1.2.3
  - privacy: 1.4.0
  - provisioning_api: 1.10.0
  - recommendations: 0.8.0
  - richdocumentscode: 6.4.705
  - settings: 1.2.0
  - sharebymail: 1.10.0
  - spreed: 10.0.6
  - support: 1.3.0
  - survey_client: 1.8.0
  - suspicious_login: 3.2.1
  - systemtags: 1.10.0
  - tasks: 0.13.6
  - text: 3.1.0
  - theming: 1.11.0
  - twofactor_backupcodes: 1.9.0
  - updatenotification: 1.10.0
  - user_status: 1.0.1
  - viewer: 1.4.0
  - weather_status: 1.0.0
  - workflowengine: 2.2.0
Disabled:
  - contacts
  - richdocuments

So yeah, it's a bit weird that app:update --all updates apps which are not enabled, but then again it could be the itention, because you can't enable the app right now unless you update it e.g. due to major upgrade with incompatibility.

But from my POV IAppManager::getInstalledAppsValues should return a list of installed apps, not a list of enabled apps? Confusing part is then:

server/lib/private/App/AppManager.php

Lines 143 to 145 in d89a75b

	$this->installedAppsCache = array_filter($values, function ($value) {
	return $value !== 'no';
	});

Although we might need both methods getInstalledApps and getEnabledApps

[nursoda]

@szaimen I had my scripts such that they do a app:update --all first, and then a update:check. I now swapped these and added some text delimiter so that I will see if the OP bug description happens again. And it did, on a 25.0.3 instance (release channel):

--- Executing update:check ---
Everything up to date
--- Executing app:update --all ---
calendar_resource_management new version available: 0.4.0
calendar_resource_management updated

Same today, on an NC 26.0.0beta1 instance (beta channel):

--- Executing update:check ---
Update for snappymail to version 2.25.2 is available.
1 update available
--- Executing app:update --all ---
contacts new version available: 5.1.0
contacts updated
snappymail new version available: 2.25.2
snappymail updated

Seems like the issue still exists.

[nursoda]

I just got the below output from the script that iterates through my instances and does

occ update:check
occ app:update --all

for each of them. The whole script runs approximately 10 seconds. Output abbreviated to such instances that show different outputs.

--- 1 latest beta, bare minimum apps plus twofactor apps ---
update:check
Everything up to date
app:update --all
twofactor_nextcloud_notification new version available: 3.6.0
twofactor_nextcloud_notification updated

--- 2 latest beta, production instance (new 26.0.0beta1install upgraded to beta2,3,4)
update:check
Update for twofactor_nextcloud_notification to version 3.6.0 is available.
1 update available
app:update --all

--- 3 latest stable, stage instance
update:check
Update for twofactor_nextcloud_notification to version 3.6.0 is available.
1 update available
app:update --all
twofactor_nextcloud_notification new version available: 3.6.0
twofactor_nextcloud_notification updated

--- 4 latest stable, production instance
update:check
Everything up to date
app:update --all

Whereas latest beta here refers to NC26.0.0.6 (beta4) and latest stable to NC25.0.3.2.

In 1, update:check claims "all apps are updated" whereas app:update finds and installs the update.

In 2, it' vice versa. Although update:check yields an update, app:update does not find it and thus doesn't install it.

In 3, both commands see the update and it is installed.

In 4, both commands don't see the update and thus do nothing.

So, what's the deal here? Running that script regularly interactively, I quite often experience that a certain app is seen and updated by some instances, and e.g. an hour later by others, and even another hour later by the rest of the instances. So both commands seem to have some local caching or a throttle that prevents them from actually asking the server. I think the issue is about that these mechanisms are not in sync for one instance in itself (and among multiple instances on one server).

[nursoda]

OR … ( I may have spoken too soon) … it's just an access issue on the apps.nextcloud.com loadbalancer or sorts:

{"reqId":"BBvGCeJOW9OcsKtm0R2x","level":2,"time":"2023-02-21T22:16:48+01:00","remoteAddr":"","user":"--","app":"appstoreFetcher","method":"","url":"--","message":"Could not connect to appstore: cURL error 7: Failed to connect to apps.nextcloud.com port 443 after 23 ms: Couldn't connect to server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://apps.nextcloud.com/api/v1/apps.json","userAgent":"--","version":"26.0.0.6","data":{"app":"appstoreFetcher"}}

[SimJoSt]

Learning about the occ update:check command, I realized there is the same issue with our instance.
As occ app:update --all runs the updates and changes the state of things, it's easier to debug with occ app:update --showonly to prevent the updates from actually running, but only show them.

I agree with some comments, that an ideal solution would provide some more context or options to either distinguish between active and disabled as well as compatible and incompatible apps or include/exclude them with an additional flag.
However, I think it would be best to rectify the outlined issue first and then approach additional features. Without code comments, it's hard to understand which behaviour is intentional and which is not.
One of those feature requests already exists as #32691