Some tweaks in r46650 to make this less likely, but deadlocks will happen with mysql on occasion. It's not an issue unless it happens all the time.

forrester.wikipedia wrote:

While running a javascript-userscript this error occurs frequently (when there are more than 3-4 calls) which at least for german wikipedia's file checking team is a quite problematic behaviour. And since there is no machine-readable 500-errormessage we cannot identify that case and do the call again. Any idea to solve this?

What does the script do?

Some tweaks in r49851

forrester.wikipedia wrote:

http://de.wikipedia.org/wiki/Benutzer:Forrester/d%C3%BCp-monobook.js

It changes some informations on several file-pages that are needed for our file checking project to do not lose files (e.g. http://de.wikipedia.org/w/index.php?title=Datei:Bhopalkart.jpg&diff=prev&oldid=59390404)

And when there are many file-pages to change at one action some are not done:

At those which are not changed firebog does not list the GET calls and the POST calls (action: submit) comprise:

<!-- start content -->

			Es ist ein Datenbankfehler aufgetreten.

Der Grund kann ein Timeout sein, der Ausfall eines Servers oder auch ein Programmierfehler.
Die letzte Datenbankabfrage lautete: <blockquote><tt>(SQL-Abfrage versteckt)</tt></blockquote> aus der Funktion „<tt>FlaggedRevision::insertOn</tt>“.
MySQL meldete den Fehler „<tt>1213: Deadlock found when trying to get lock; Try restarting transaction (10.0.6.23)</tt>“.

Update synopsis

Tweaks in r49851, r49889

forrester.wikipedia wrote:

And do you think that this could solve the problem? One alternative that I was told to present would be to make this error machine-readable (error 500) so that if it occurs a userscript could send the call again.

Is this using the API or doing a RevisionReview hit like the UI does?

forrester.wikipedia wrote:

it's not using the API, it's emulating the UI using action=edit and submitting shortly afterwards.

forrester.wikipedia wrote:

Can I expect some improvements or is this problem non-changeable?

Changes have been made, but not synced.

forrester.wikipedia wrote:

And do you think that those changes solve the problem or make it less likely to occur?

As I said on CodeReview, I believe the use of LOCK IN SHARE MODE will make this bug happen more, rather than less. Deadlocks can be avoided completely by just not using locking reads.

Fixed in r51269