Why workflow_ocr cares about a deleted file?

[mf-in-mun]

Hello,

since a day ago I got the following warning in the Nextcloud logs:

{
  "reqId": "blL9tczS2WYDoAsfMYwU",
  "level": 2,
  "time": "2026-05-20T12:10:42+00:00",
  "remoteAddr": "10.0.2.100",
  "user": "Jon",
  "app": "workflow_ocr",
  "method": "GET",
  "url": "/ocs/v2.php/apps/notifications/api/v2/notifications",
  "scriptName": "/ocs/v2.php",
  "message": "Could not find file with id 49515 for user Jon",
  "userAgent": "Mozilla/5.0 (Linux) Nextcloud-Talk v2.1.2",
  "version": "33.0.3.2",
  "data": {
    "app": "workflow_ocr"
  }
}

I've done some checkups:

php occ files:get 49515 -> file 49515 not found

php occ files:delete 49515 -> file 49515 not found

php occ files:cleanup -> no change
php occ files:scan -> no change
php occ files:sanitize-filenames -> no change
php occ files:repair-tree -> no change

Then I've deleted the workflow and created a new one with the same parameters.
But the warning remains.

Now I'm out of ideas what to do.

Is there any idea to get rid of these warnings?

Any help is really appriciated.

BR SMF

System: Nextcloud 33.0.3, containerized but it's not the AIO solution, rootless Podman pod, workflow_ocr 1.33.1, workflowengine 2.15.0, Almalinux 10.1, Podman 5.6.0,

[oraculix]

Excuse the necro-bump, @mf-in-mun, but how did you resolve this in the end?
I have the same issue and tried the same steps to no avail.

• Workflow version 1.34.0
• Nextcloud AIO 34.0.1

[mf-in-mun]

@oraculix,

I've solved it kind of.

It seemed to be happen when a file is deleted before it's processed by the OCR workflow.
I just restarted the whole! Nextcloud service and mostly the error has gone.
Restarting the service is not a big deal in my homelab.

BR SMF

[oraculix]

Thanks for the quick reply.

I just restarted the whole!

That didn't work for me, unfortunately. Neither maintenance on/off, nor container restart nor a restart of the host VM.
So problably my case is a bit different, and as I do not have permissions to re-open the issue, I'll create a new one.

[mf-in-mun]

@oraculix

please refer to this issue.
I will give your's a thumb up and maybe we can push it a little.

[R0Wi]

No need to push anything, I'm always open to discuss 😉

Is it still about the initial problem that logs are created if the workflow processing picks up a file that has been deleted in the meantime?

[oraculix]

Thanks @R0Wi,

I suppose it is the same reason. While working with a particular file I had it overwritten and deleted several times, sometimes before workflow_ocr picked the file up. I also had a full file system issue recently, but from the logs it looks like the missing file warnings were already issued earlier than that.

[R0Wi]

Ok so the main issue here is a warning entry in the logs? The more I think about it, the more I think we should change the log level to debug. As you described, this situation can occur but the app should just skip the processing in that case

[oraculix]

Yes, the permanent warning entry is the main issue (3 entries per file per 50s in my case).
A debug entry sounds good — when it's accompanied with a change in the application behaviour, e. g., skip this file ID after n unsuccessful tries.