Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

occ update:check and occ app:update --all don't match #26203

Open
joekerna opened this issue Mar 18, 2021 · 10 comments
Open

occ update:check and occ app:update --all don't match #26203

joekerna opened this issue Mar 18, 2021 · 10 comments

Comments

@joekerna
Copy link

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 MorrisJobke transferred this issue from nextcloud/updater Mar 19, 2021
@MorrisJobke
Copy link
Member

cc @nickvergessen

@skjnldsv skjnldsv added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug feature: install and update labels Mar 22, 2021
@joekerna
Copy link
Author

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
Copy link
Member

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

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

While app:update --all loops over:

$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
Copy link
Author

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
Copy link
Member

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:

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

Although we might need both methods getInstalledApps and getEnabledApps

@szaimen szaimen added 2. developing Work in progress and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Jun 25, 2021
@szaimen

This comment has been minimized.

@szaimen szaimen added needs info 0. Needs triage Pending check for reproducibility or if it fits our roadmap and removed 2. developing Work in progress labels Jan 23, 2023
@nickvergessen nickvergessen added 1. to develop Accepted and waiting to be taken care of 26-feedback and removed needs info 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Jan 23, 2023
@nursoda
Copy link

nursoda commented Feb 1, 2023

@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
Copy link

nursoda commented Feb 21, 2023

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
Copy link

nursoda commented Feb 21, 2023

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
Copy link
Contributor

SimJoSt commented Dec 15, 2023

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

@joshtrichards joshtrichards changed the title update:check and app:update --all don't match occ update:check and occ app:update --all don't match Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants