Limit logged HTTP responses size to a reasonable level in case of connection errors

[major-mayer]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
I'm always frustrated when Nextcloud's appstore fetcher encounters connection timeouts and logs massive HTTP response bodies (up to 8MB) that get sent to me via email. This happens because I run Nextcloud's cron tasks every 5 minutes using php -f /var/www/nextcloud/cron.php, and any stderr output from these tasks gets automatically emailed to me - which is exactly what I want for monitoring actual errors in the cron jobs.

However, when the appstore fetcher times out while downloading from https://apps.nextcloud.com/api/v1/apps.json, it logs the entire partial response body at warning level. This creates two log entries that flood my email inbox:

Currently, I receive two log entries:

1. A concise warning: "Response from appstore is invalid, apps could not be retrieved. Try again later."

{
 "reqId": "Z1Vogfmpj8XewuoZO2yU",
"level": 2,
"time": "2025-09-10T04:07:36+00:00",
"remoteAddr": "",
"user": "--",
"app": "appstoreFetcher",
"method": "",
"url": "--",
"message": "Response from appstore is invalid, apps could not be retrieved. Try again later.",
"userAgent": "--",
"version": "31.0.7.1",
"data": {
"app": "appstoreFetcher"
 }

2. A massive debug dump containing the full HTTP response body and stack trace

Details

{
    "reqId": "Z1Vogfmpj8XewuoZO2yU",
    "level": 3,
    "time": "2025-09-10T04:07:36+00:00",
    "remoteAddr": "",
    "user": "--",
    "app": "no app in context",
    "method": "",
    "url": "--",
"message": "{\"Exception\":\"GuzzleHttp\\\\Exception\\\\ConnectException\",\"Message\":\"cURL error 28: Operation timed out after 60000 milliseconds with 8851122 out of 8914870 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for [https://apps.nextcloud.com/api/v1/apps.json\",\"Code\":0,\"Trace\":[{\"file\":\"/var/www/html/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php\",\"line\":205,\"function\":\"createRejection\",\"class\":\"GuzzleHttp\\\\Handler\\\\CurlFactory\",\"type\":\"::\",\"args\":[\"***](https://apps.nextcloud.com/api/v1/apps.json/%22,/%22Code/%22:0,/%22Trace/%22:[%7B/%22file/%22:/%22/var/www/html/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php/%22,/%22line/%22:205,/%22function/%22:/%22createRejection/%22,/%22class/%22:/%22GuzzleHttp////Handler////CurlFactory/%22,/%22type/%22:/%22::/%22,/%22args/%22:[/%22***) sensitive parameters replaced \"]},{\"file\":\"/var/www/html/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php\",\"line\":157,\"function\":\"finishError\",\"class\":\"GuzzleHttp\\\\Handler\\\\CurlFactory\",\"type\":\"::\",\"args\":[{\"class\":\"GuzzleHttp\\\\Handler\\\\CurlHandler\"},\" sensitive parameters replaced ***\",{\"class\":\"GuzzleHttp\\\\Handler\\\\CurlFactory\"}]},{\"file\":\"/var/www/html/3rdparty/guzzlehttp/guzzle/src/Handler/CurlHandler.php\",\"line\":47,\"function\":\"finish\",\"class\":\"GuzzleHttp\\\\Handler\\\\CurlFactory\",\"type\":\"::\",\"args\":[{\"class\":\"GuzzleHttp\\\\Handler\\\\CurlHandler\"}, ...
"userAgent": "--",
    "version": "31.0.7.1"
}

The workaround of increasing log level to 3 means I miss legitimate warnings that I want to monitor.

Describe the solution you'd like
I would like Nextcloud to implement intelligent log truncation for HTTP response bodies, especially for network timeouts and connection errors. Specifically:

1. Response body truncation: Limit logged HTTP response content to a reasonable size (e.g., first 1KB and last 1KB with "... [X bytes truncated] ..." in between)
2. Separate log levels: Keep the concise error message at warning level, but move the detailed technical dump to debug level
3. Configuration option (optional): Add a config parameter like log_max_response_body_size to control the maximum size of HTTP responses that get fully logged

Describe alternatives you've considered

• Increasing log level to 3: This works but causes me to miss legitimate warnings
• Email filtering: Doesn't solve the underlying issue of oversized logs

Additional context
Add any other context or screenshots about the feature request here.