do not explode when getting permissions from a FailedStorage

[blizzz]

for instance if a user of an external user backend is not available
currently, the whole Files UI would be frozen.

[MorrisJobke]

CI failure unrelated.

Beside that: should we somehow clean this up? Or is this already done in the background job that does the cleanup of orphaned shares?

[blizzz]

Beside that: should we somehow clean this up? Or is this already done in the background job that does the cleanup of orphaned shares?

I don't think it is done. Normally, when properly deleting a user, the entries also vanish. It is also an edge case here, because it comes with another condition that a username was removed (LDAP → clear mappings) and not repopulated. It's rather a consideration to change the behaviour there and also run the whole standard deletion process. As a fundamental change that's nothing to backport.

It's still OK to catch this to ensure the Files view is working. Still, should not be an apology for strange behaving user backends or admins.

[blizzz]

For the record, we have had just another case that went into the same trap, but was not related to missing users. Worse, it did not generate any log output. But it is fixed with that check as well.

This makes me wonder whether the original change actually does what is is supposed to do @rullzer #11041 in apps/files_sharing/lib/Cache.php