I don't see anything in the API that seems like it would result in deadlocks here, so I'm going to move it to "non-core-API stuff" for now add MediaWiki-Special-pages to investigate it from that angle. The API module is pretty simple and just calls MovePage to do most of the work.

At first glance I didn't see anything in MovePage that would obviously cause a deadlock either, but I didn't track through it too closely.

I suggest to close this rather than keep it around if someone already checkit. No reason to keep a backlog if it is not clearly actionable, and we can reopen if it reoccurres. Normally I don't create a ticket for this kind of errors, but I was worried that it kept happening for days rather than hours of minutes.

The deadlocks came back, so I don't think we can close this for now. I still do not think it is high priority, but it is an ongoing event: https://logstash.wikimedia.org/goto/e5a2230fb3cd9c90155d5391fa54a484

Not sure if related, but now there seems to be contention on cebwiki for LinksUpdate::updateLinksTimestamp this one looks more like a structural problem, as it seems a lot of connections are trying to update the same page row at the same time:

Deadlock found when trying to get lock; try restarting transaction (10.64.48.25)	UPDATE  `page` SET page_links_updated = '20190514085248' WHERE page_id = '7934287'

Cebwiki is known for the huge usage of templates, so this could be an edge case that may be interesting for Performance-Team on page move or page update

Possibly related:

• Database deadlock from category update: T206283: Failed deferred updates should be queued as jobs if possible (Deadlock from LinksUpdate in WikiPage::updateCategoryCounts)
• Database deadlock from MovePage: T223175: Fatal DB error when moving pages: Duplicate entry for key 'name_title' / Lock contention / Deadlock

There doesn't seem to be an action for Editing so I am removing our tag.