[marcelklehr]

Summary

getFirstNodeById will throw if it gets anything other than an int.

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

[marcelklehr]

/backport to stable32

[marcelklehr]

/backport to stable33

[max-win-at]

Independent confirmation on a current release, in case it helps this land.

Environment: Nextcloud 35.0.2 (build 35.0.2.2), docker.io/library/nextcloud:35-apache, PHP 8.5.12, task type core:image2text:ocr (input shape ListOfFiles), provider served by an external app through AppAPI.

Repro — form-encoded, which is how most scripts call OCS:

curl -u user:pass -H 'OCS-APIRequest: true' -X POST \
  --data-urlencode 'type=core:image2text:ocr' \
  --data-urlencode 'appId=my_exapp' \
  --data-urlencode 'input[input][0]=12345' \
  'https://cloud.example.com/ocs/v2.php/taskprocessing/schedule?format=json'

→ OCS 996 Internal Server Error, and in nextcloud.log:

OC\Files\Node\LazyFolder::getFirstNodeById(): Argument #1 ($id) must be of type int, string given,
called in /var/www/html/lib/private/TaskProcessing/Manager.php on line 1897

The same request with a JSON body succeeds:

-d '{"type":"core:image2text:ocr","appId":"my_exapp","input":{"input":[12345]}}'
-H 'Content-Type: application/json'

Why: validateInput() casts with (int) for its own check but does not rewrite the task input, so the later access check — foreach ($ids as $fileId) { $this->validateFileId($fileId); … } — hands the raw numeric string to the strictly-typed getFirstNodeById(int $id). The PR's normalisation in validateFileId() covers exactly this.

Not a regression, and not new in 35. I diffed lib/private/TaskProcessing/Manager.php between 34.0.5 and 35.0.2: validateFileId(), declare(strict_types=1) and the access-check loop are identical in both — only line numbers moved (34: 1594/1737 → 35: 1753/1896). So this has been reachable since at least 34.0.5, which makes it a long-standing API bug rather than something 35 introduced.

Until this lands, the workaround is to send JSON rather than form fields.

[marcelklehr]

/backport to stable34

[marcelklehr]

/backport to stable35