nextcloud/collectives

Error while running background job OCA\Collectives\BackgroundJob\IndexCollectives

Closed this issue · 1 comments

davidfrickert commented

Describe the bug
Nextcloud logs are full of errors on IndexCollectives cronjob, e.g.:

file_get_contents(/var/www/html/data/appdata_ocrblmvzwlmq/collectives/1/Kubernetes Cluster/Migrations.md): Failed to open stream: No such file or directory at /var/www/html/lib/private/Files/Storage/Local.php#331

Looking at the filesystem, this file indeed does not exist, as it is a folder, due to it being a parent page to other subpages.

root@nextcloud-555c8b79f9-9c56s:/var/www/html/data/appdata_ocrblmvzwlmq/collectives/1/Kubernetes Cluster# ls
Debugging  Migrations  Readme.md  Renovate  Storage
root@nextcloud-555c8b79f9-9c56s:/var/www/html/data/appdata_ocrblmvzwlmq/collectives/1/Kubernetes Cluster# cd Migrations/
root@nextcloud-555c8b79f9-9c56s:/var/www/html/data/appdata_ocrblmvzwlmq/collectives/1/Kubernetes Cluster/Migrations# ls
 Readme.md  'SQlite3 to Postgres.md'

This is an example structure that gives these errors in the logs:

image

To Reproduce
?

Expected behavior
No errors in logs from IndexCollectives

Screenshots
If applicable, add screenshots to help explain your problem.

Server details:

  • Collectives app version: 2.14.2
  • Nextcloud version: 29.0.5
  • PHP Version: ? (official NC docker image)
  • Database: Postgres 16.3
Logs

Nextcloud log (data/nextcloud.log)

GenericFileException Error while running background job OCA\Collectives\BackgroundJob\IndexCollectives (id: 76559, arguments: null)
Error while running background job OCA\Collectives\BackgroundJob\IndexCollectives (id: 76559, arguments: null)
	
file_get_contents(/var/www/html/data/appdata_ocrblmvzwlmq/collectives/1/Kubernetes Cluster/Migrations.md): Failed to open stream: No such file or directory at /var/www/html/lib/private/Files/Storage/Local.php#331
mejo- commented

Thanks for the report @davidfrickert, good finding. It seems like some files went missing on your filesystem while they're still indexed in the filecache database table. Still, indexing shouldn't error in this case. I'll push a fix.