[MarioPym]

Summary

Requests sent by OCA\Files_Sharing\External\Storage to remote servers, including the shareinfo request and the reachability checks (e.g. against status.php or ocm-provider), rely on a hardcoded 10-second timeout. When the remote server is under heavy load, it may take longer than 10 seconds to respond to shareinfo, even though only the root of the share is requested (depth 0). The request then fails with cURL error 28 and the share is reported as unavailable, with no way to adjust the limit (a similar limitation was reported in #29941).

This change introduces the sharing.federation.request_timeout system configuration option (in seconds, defaulting to 10), which applies to both timeout and connect_timeout for these requests, and documents it in config.sample.php. The default value preserves the existing behavior. WebDAV requests for the same storage are unaffected and continue to use davstorage.request_timeout.

How to test

1. Create a federated share from a remote server whose /index.php/apps/files_sharing/shareinfo takes more than 10 seconds to answer (e.g. a remote that delays the response by 15 s, such as a sleep(15) added to ShareInfoController::info() for testing).
2. Accept the share and open it.
   • Before: getShareInfo() fails after 10 s with cURL error 28: Operation timed out after 10000 milliseconds.
3. occ config:system:set sharing.federation.request_timeout --type=integer --value=20 and open it again.
   • After: the request completes (about 15 s in my test).
4. Without the key the behavior is unchanged (fails after 10 s).

Unit test: apps/files_sharing/tests/ExternalStorageTest.php.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[provokateurin]

What are "large federated shares" and "a big share, or a remote that delays the response by 15 s" supposed to mean?

[MarioPym]

What are "large federated shares" and "a big share, or a remote that delays the response by 15 s" supposed to mean?

You're right, that part of the description is wrong. It isn't about the size of the share: the server only requests the root of the share (depth 0), so the share size doesn't matter. The issue happens when our instances are under heavy load (high traffic): the remote takes longer to answer shareinfo, and we've seen responses taking between 10 and 30 seconds. In our logs, around 200 of these requests eventually succeeded within that range; with the fixed 10 s limit they would have failed and the share would have been shown as unavailable. I've updated the description accordingly.