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.

[R0Wi]

Ok so it sounds like just changing the log level from WARN to DEBUG wouldn't solve the issue, right?

3 entries per file per 50s in my case

This sounds like you're seeing some kind of retry behavior already? I'm wondering where this might come from since we do not proactively implement a retry pattern. Also, if a file does not exist, a NotFoundException would be thrown. The exception will be definitely caught here. It will be turned into an ERROR log and a new Nextcloud notification will be created for the user.

Sorry for asking once more but could you elaborate again on the current behavior you're observing and tell me exactly, what would be the expected outcome?

[oraculix]

This sounds like you're seeing some kind of retry behavior already?

Yes, exactly.
While looking at my NC Logs, I noticed the recurring warning message "Could not find file with id xxxxx for user yyy". For now, I haven't found a way to stop these messages from appearing and cluttering my logs.

I have that feeling that there's something stuck in the database. But OTOH I already ran repairs like OP:

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

Expected outcome: No more warning messages for a file that doesn't exist.

[R0Wi]

Thanks for the clarification. I think I understood the issue now. Still I'm wondering where this "retry-behavior" might come from.

Would it be possible to share the logs with timestamps? Ideally we would see the stacktrace and are able to determine, where the workflow is being called.