fix(sharing): Avoid (dead)locking during orphan deletion

[ChristophWurst]

• Resolves: Doctrine\DBAL\Exception\LockWaitTimeoutException: An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction #27695

Summary

Concurrent modifications of shared entries in oc_filecache makes the share orphan background job lock. This is fine. If the row is UPDATED, we don't care. If the row is DELETEd, the next background job will catch it.

This replaces widely locking DELETE with SELECT+DELETE. See code comments.

How to test

The real world (dead)lock is hard to reproduce in a lab setup. You have to simulate concurrent modifications of filecache.

1. Log into Nextcloud
2. Create two folders f1 and f2
3. Share both folders with another user
4. Delete f2
5. Go to trash bin and delete f2 permanently
6. Open a database shell
   1. Run SELECT id FROM oc_jobs WHERE class = 'OCA\\Files_Sharing\\DeleteOrphanedSharesJob'. Note down the job id.
   2. Run SELECT file_target, file_source FROM oc_share ORDER BY id DESC LIMIT 2;. These are your f1 and f2 shares. Note down the file_source of f1.
   3. Run SELECT storage, path_hash FROM oc_filecache WHERE fileid=<file_source>;. Note down storage and path_hash values.
   4. Run START TRANSACTION;
   5. Run UPDATE `oc_filecache` SET `mtime` = GREATEST(`mtime`, 1706777193), `etag` = '659cf751000cd' WHERE (`storage` = <storage>) AND (`path_hash` IN (<path_hash>));
7. Run php occ background-job:execute <id> --force-execute

master: job will stall. Run ROLLBACK; in the datbase shell to unlock the occ command.
here: job will finish and clean up the oc_share entry of f2 despite the lock on f1's filecache entry. Run ROLLBACK; to unlock your dev env for other operations ;-)

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)

[ChristophWurst]

The old test still passes. This is good to go.

[ChristophWurst]

/backport to stable28

[ChristophWurst]

/backport to stable27

[ChristophWurst]

/backport to stable26

[come-nc]

Is it not cleaner to select everything and chunk the deletes with array_chunk? It avoids the premature stop I think.

[ChristophWurst]

Avoids the stop but could exhaust memory if there are lots of orphans

[solracsf]

Avoids the stop but could exhaust memory if there are lots of orphans

Agree, same as #41272

[come-nc]

Hum ok but that would mean like a LOT of orphans. Other things will break first :-P

Anyway, fine with either approach.

[icewind1991]

I've also created #43605 to reduce the interval from every 15m to daily

[ChristophWurst]

This is done

[nickvergessen]

Conflicting due to #43605

[icewind1991]

rebased