[Bug]: Serialization failure: 1213 Deadlock error lead to a "conflict" the next time sync runs

[kimmerin]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Since all serialization-deadlock issues (like #22482 or #27904) are closed or blocked, preventing new comments, I need to open a new issue to add some information.

I've set up a new Nextcloud-instance and during the process of initial upload I run into lots of serialization-errors as described in the issues. The next time the sync runs I occasionally run into conflicts which should be impossible because - as mentioned - this is an initial upload of files from one client, so it's impossible that a second client uploaded a different version of a file at the same time. I don't have many measure points but it looks like the files on the server are always smaller than the local ones, giving me the impression that they are incomplete uploads not recognizes as such on the server side. The deadlock-messages are the only messages that happened during upload so I think these two issues might be related.

If that's the case, the view "nothing serious, the process just repeats the next time" isn't 100% correct because there seem to be cases where corrupt data resides on the server after such an error that might be downloaded by other clients before the fixing reupload starts.

Steps to reproduce

See reproducing steps in the other issues about this issue.

Expected behavior

An incomplete upload should be recognized by the server (if that's what's happening leading to the effect)

Installation method

Community Manual installation with Archive

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.0

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "xxx.xxx.xxx.xxx"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "24.0.6.1",
        "overwrite.cli.url": "http:\/\/xxx.xxx.xxx.xxx\/nextcloud",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true
    }
}

List of activated Apps

Enabled:
  - accessibility: 1.10.0
  - activity: 2.16.0
  - bruteforcesettings: 2.4.0
  - calendar: 3.5.0
  - circles: 24.0.1
  - cloud_federation_api: 1.7.0
  - comments: 1.14.0
  - contacts: 4.2.2
  - contactsinteraction: 1.5.0
  - dashboard: 7.4.0
  - dav: 1.22.0
  - federatedfilesharing: 1.14.0
  - federation: 1.14.0
  - files: 1.19.0
  - files_pdfviewer: 2.5.0
  - files_rightclick: 1.3.0
  - files_sharing: 1.16.2
  - files_trashbin: 1.14.0
  - files_versions: 1.17.0
  - files_videoplayer: 1.13.0
  - firstrunwizard: 2.13.0
  - logreader: 2.9.0
  - lookup_server_connector: 1.12.0
  - mail: 1.13.9
  - nextcloud_announcements: 1.13.0
  - notifications: 2.12.1
  - oauth2: 1.12.0
  - password_policy: 1.14.0
  - photos: 1.6.0
  - privacy: 1.8.0
  - provisioning_api: 1.14.0
  - recommendations: 1.3.0
  - richdocuments: 6.2.0
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - sharebymail: 1.14.0
  - spreed: 14.0.5
  - support: 1.7.0
  - survey_client: 1.12.0
  - systemtags: 1.14.0
  - text: 3.5.1
  - theming: 1.15.0
  - twofactor_backupcodes: 1.13.0
  - updatenotification: 1.14.0
  - user_status: 1.4.0
  - viewer: 1.8.0
  - weather_status: 1.4.0
  - workflowengine: 2.6.0
Disabled:
  - admin_audit
  - encryption
  - files_external
  - user_ldap

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

[webdav] Fatal: Doctrine\DBAL\Exception\DeadlockException: An exception occurred while executing a query: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction at <<closure>>

 0. /var/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php line 1780
    Doctrine\DBAL\Driver\API\MySQL\ExceptionConverter->convert()
 1. /var/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php line 1719
    Doctrine\DBAL\Connection->handleDriverException()
 2. /var/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php line 1173
    Doctrine\DBAL\Connection->convertExceptionDuringQuery()
 3. /var/www/nextcloud/lib/private/DB/Connection.php line 294
    Doctrine\DBAL\Connection->executeStatement()
 4. /var/www/nextcloud/3rdparty/doctrine/dbal/src/Query/QueryBuilder.php line 354
    OC\DB\Connection->executeStatement()
 5. /var/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php line 281
    Doctrine\DBAL\Query\QueryBuilder->execute()
 6. /var/www/nextcloud/lib/private/Files/Cache/Cache.php line 382
    OC\DB\QueryBuilder\QueryBuilder->execute()
 7. /var/www/nextcloud/lib/private/Files/Cache/Updater.php line 256
    OC\Files\Cache\Cache->update("*** sensitive parameters replaced ***")
 8. /var/www/nextcloud/lib/private/Files/Cache/Updater.php line 161
    OC\Files\Cache\Updater->correctParentStorageMtime()
 9. /var/www/nextcloud/lib/private/Files/View.php line 334
    OC\Files\Cache\Updater->remove()
10. /var/www/nextcloud/lib/private/Files/View.php line 1189
    OC\Files\View->removeUpdate()
11. /var/www/nextcloud/lib/private/Files/View.php line 355
    OC\Files\View->basicOperation()
12. /var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php line 318
    OC\Files\View->rmdir()
13. /var/www/nextcloud/apps/dav/lib/Upload/FutureFile.php line 100
    OCA\DAV\Connector\Sabre\Directory->delete()
14. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Tree.php line 164
    OCA\DAV\Upload\FutureFile->delete()
15. /var/www/nextcloud/apps/dav/lib/Upload/ChunkingPlugin.php line 94
    Sabre\DAV\Tree->move()
16. /var/www/nextcloud/apps/dav/lib/Upload/ChunkingPlugin.php line 76
    OCA\DAV\Upload\ChunkingPlugin->performMove()
17. /var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php line 89
    OCA\DAV\Upload\ChunkingPlugin->beforeMove()
18. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php line 603
    Sabre\DAV\Server->emit()
19. /var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php line 89
    Sabre\DAV\CorePlugin->httpMove()
20. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 472
    Sabre\DAV\Server->emit()
21. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 253
    Sabre\DAV\Server->invokeMethod()
22. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 321
    Sabre\DAV\Server->start()
23. /var/www/nextcloud/apps/dav/lib/Server.php line 358
    Sabre\DAV\Server->exec()
24. /var/www/nextcloud/apps/dav/appinfo/v2/remote.php line 35
    OCA\DAV\Server->exec()
25. /var/www/nextcloud/remote.php line 166
    require_once("/var/www/nextcl ... p")

MOVE /nextcloud/remote.php/dav/uploads/user/3066096469/.file
from 192.168.1.40 by user at 2022-10-20T09:38:06+00:00

Additional info

No response

[GieltjE]

Can report the same, #29985 is another one.
Simply unpack something like ghidra (easy example), and upload it through the desktop client ("Network Error:99") or through the webui ("An exception occurred while executing a query: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock;").

[obel1x]

@kimmerin
There is an open one #6899 - and my solution to reduce deadlocks by changing indices on table oc_filecache. Can you check #6899 (comment) and leave a thumb up if it works?

[szaimen]

Hi, please update to 25.0.7 or better 26.0.2 and report back if it fixes the issue. Thank you!

My goal is to add a label like e.g. 26-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!

If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+

[obel1x]

@szaimen
Hi Simon, please at first have a look at my explanation here: #29985 (comment)

As long, as filehandling while uploading is not changed, that error will persist. I would rate it mayor as it affects basic functionality and occurs very often doing some trouble (e.g. needs to upload files again, show errors that are not inituitve). I dont' think anyone did take a look in neither version, so this will not change either (or had someone?).

There are some ways to reduce occurence, like:

1. Use Postgres
2. Remove Indices (as explained here: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction #6899 (comment))
3. Try some DB-Tweaks in config

But they ALL do not solve the Problem itself (while 2. would dramatically reduce database size by half for the caching table without loosing functionality)

Please do not close those issues, as this only makes more "paperwork". The problem will not solve without adjusting the code, so only way to get rid of issues is to changed that part.
I would love someone to take a look at those directory- size- calculations and make it fast and relyable for the future.
Imo Nextcloud is just too good for those nasty bugs :) hf and gl

[szaimen]

Hi, there have been patches to address this issue that will land in 26.0.3. Can you please verify if 26.0.3-rc1 improves the situation around this issue?

[kubrickfr]

I'm on 27.0.0 and the error persists