Don't disable apps for errors in unrelated code paths

[ChristophWurst]

Steps to reproduce

1. Run Nextcloud
2. Run into an unhandled exception during app initialization phase
3. See unrelated apps getting disabled

Expected behaviour

We only disable apps if it's really their fault and the error was triggered there.

Actual behaviour

If apps call some other app's or server code and that causes an exception (database or redis down, for example) that app is wrongly disabled. Leading to other bugs and unwanted behavior.

Server configuration

Nextcloud version:

any

---

cc @blizzz @nickvergessen @rullzer

[nickvergessen]

yeah, well its kind of hard to figure out what is temporary, what needs the app disabled and what not.

[klada]

There are some apps which should never be automatically disabled at all, once enabled (such as authentication backends). We just had this happen (user_saml was disabled) and as soon as this happened hundreds of sync clients started going crazy, which obviously causes a lot of workload for user support in bigger environments.

IMHO it would also be fine to prevent auto-disabling of specific apps through a config entry (similar to alwaysEnabled in core/shipped.json), as it would at least prevent the scenario I just described from happening again. Or you could just exclude any app of type authentication from this auto-disabling behavior.

[nickvergessen]

Also files_accesscontrol should e.g. not be disabled but preferably break things.
Same for external storages I guess, before they remove tons of data from all sync clients?

[rullzer]

Lets tackle it in steps.

Lets first make sure that authentication apps do not get auto disabled.