[Bug]: PROPFIND request returns 207 with empty directory on storage exception

[Antreesy]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

If storage (e.g. external) fails during operation, exception is captured but ignored. Server response still comes with status 207

server/lib/private/Files/View.php

Lines 1589 to 1600 in cbbbe5a

	try {
	$subScanner->scanFile('');
	} catch (StorageNotAvailableException|StorageInvalidException) {
	continue;
	} catch (\Exception $e) {
	// sometimes when the storage is not available it can be any exception
	$this->logger->error('Exception while scanning storage "' . $subStorage->getId() . '"', [
	'exception' => $e,
	'app' => 'core',
	]);
	continue;
	}

Clients can't tell the difference between no children in folder and failed to reach children and might wrongly interpret the signal (e.g. a desktop client can read this as 'child deleted on server' and drop local files, then send signal to clean server folder on next sync

Steps to reproduce

Basic reproduction with hardcoded logic to throw an exception:

1. Create and mount external storage inside a parent folder, confirm PROPFIND returns 207 with all children listed.
2. Clear the file cache root entry for mount, to force inside if (!$rootEntry) branch.
3. Hardcode to throw StorageNotAvailableException inside that branch for this mount.
4. Confirm PROPFIND returns 207, without failed mount listed.

Expected behavior

Request should either:

• return different status, e.g. 503 Service Unavailable
• pass attribute, to inform clients of incomplete response

Depending on client expectation/readyness for the breaking change, it can be opt-in for backported versions, and default with coming major releases

Nextcloud Server version

32

Operating system

None

PHP engine version

PHP 8.3

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

-

List of activated Apps

-

Nextcloud Signing status

-

Nextcloud Logs

-

Additional info