[Bug]: cron fails because of gd-webp

[ProductiveAsparagus56]

⚠️ This issue respects the following points: ⚠️

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

Bug description

Animated webp are not supported and will generate gd-webp cannot allocate temporary buffer at /var/www/html/lib/private/legacy/OC_Image.php#751 as described in #37263 but this will also prevent cron from running successfully.

I have also tried to disable image previews but that didn't seem to help, you can see the line "enable_previews": false, in the config.

Steps to reproduce

1. Upload animated webp
2. get gd-webp cannot allocate temporary buffer error log
3. run cron script

Expected behavior

Let cron carry on like normal

Installation method

Community Docker image

Nextcloud Server version

29

Operating system

None

PHP engine version

None

Web server

None

Database engine version

MariaDB

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

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

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

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "upgrade.disable-web": true,
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "29.0.0.19",
        "overwrite.cli.url": "http:\/\/localhost",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "enable_previews": false,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

No response

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

{"reqId":"-","level":3,"time":"2024-05-27T14:10:02+00:00","remoteAddr":"","user":"--","app":"PHP","method":"","url":"--","message":"gd-webp cannot allocate temporary buffer at /var/www/html/lib/private/Blurhash/Listener/GenerateBlurhashMetadata.php#117","userAgent":"--","version":"29.0.0.19","data":{"app":"PHP"}}

Additional info

No response

[joshtrichards]

sigh (not directed at you; just frustrated at these preview processing matters).

38364 should address this too since I think you're only hitting that code path due to the fallback in place:

https://github.com/nextcloud/server/blob/36ae775aa7c9af22bf33645a2d8807206ec6c85f/lib/private/Blurhash/Listener/GenerateBlurhashMetadata.php#L88-L97

Thanks for reporting. I'll try to get that PR in. It's been on the back burner for awhile.

[ProductiveAsparagus56]

No problem, i understand. Is there maybe a setting where we can disable all previews and prevent these errors for now?

[ProductiveAsparagus56]

The cron issue seems to have fixed itself, but should we keep this issue open in case anything else happens?