API Edit conflict despite no one is editing with appendtext when editing through redirect
Closed, ResolvedPublic


At Wikimedia Commons, we have scripts to start deletion requests. These scripts notify the uploader of the affected file(s).

Current behaviour:
Details: See below.
When making an edit request with token and everything else right, an edit conflict is thrown, despite using option appendtext, not setting a base timestamp and no one is actually editing the page. This was reported by several users to me and you can look at https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors for a long list of edit conflicts.
The script is smart and if it detects an editconflict and recognizes that option appendtext was used, it retries 10 times (with an increasing timeout between the requests). But ALL of them failed when I made the test (list of servers below).

Expected behaviour:
Either only edit conflicts when someone else is editing the page or no edit confilct for options appendtext and prependtext.

action edit
appendtext {{subst:idw|2=Files uploaded by Rillke|3=plural}} Affected: * [[:File:Verbotsschild Hunde und Fahrradfahrer.jpg]] And also: * [[:File:Nanas - Niki de Saint Phalle 05.jpg]] * [[:File:Nanas - Niki de Saint Phalle 04.jpg]] * [[:File:Nanas - Niki de Saint Phalle 03.jpg]] * [[:File:Nanas - Niki de Saint Phalle 02.jpg]] * [[:File:Nanas - Niki de Saint Phalle 01.jpg]] If you have a question concerning this process, answer below, or in case of a deletion request, on the deletion-discussion page. Do not ask on my discussion page. With best regards ~~~~
format json
redirect true
summary Some of your [[Commons:Deletion requests/Files uploaded by Rillke|uploads have been nominated for deletion]].
title User talk:Rillke
token XXXXXX+\
watchlist watch

Accept application/json, text/javascript, */*; q=0.01
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Content-Length 952
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Cookie XXXX; centralnotice_bucket=0; popTz=0
Host commons.wikimedia.org
Referer https://commons.wikimedia.org/wiki/Commons:Village_pump
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
X-Requested-With XMLHttpRequest

{"servedby":"mw73","error":{"code":"editconflict","info":"Edit conflict detected"}}

Cache-Control private
Connection keep-alive
Content-Encoding gzip
Content-Length 91
Content-Type application/json; charset=utf-8
Date Sat, 10 Nov 2012 23:01:13 GMT
MediaWiki-API-Error editconflict
Server nginx/0.7.65
Vary Accept-Encoding
Via 1.1 sq36.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq38.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq40.esams.wikimedia.org:80 (squid/2.7.STABLE9)
X-Cache MISS from sq36.wikimedia.org, MISS from amssq38.esams.wikimedia.org, MISS from amssq40.esams.wikimedia.org
X-Cache-Lookup MISS from sq36.wikimedia.org:3128, MISS from amssq38.esams.wikimedia.org:3128, MISS from amssq40.esams.wikimedia.org:80
X-Vary-Options Accept-Encoding;list-contains=gzip
x-content-type-options nosniff
x-frame-options SAMEORIGIN

Same result (editconflict) from:

Version: unspecified
Severity: major


bzimport set Reference to bz41990.
Rillke created this task.Nov 10 2012, 11:27 PM

It seems to be related to the fact that all these pages where it happens are redirects

Since this never happened before adding keyword "code-update-regression"

This appears to be a regression due to ContentHandler: the old code used the last revision timestamp of the redirect target in this situation, while ContentHandler's changes (accidentally?) made it use the last revision timestamp of the redirect itself. ContentHandler is also using the contentmodel and contentformat of the redirect page itself for the edit, which is also probably going to be more wrong than using the model and format of the target.

Gerrit change 33049 fixes both issues.

Merged by Reedy. Looks like he deployed it at about 15:30. Is this fixed now?

Works. Thanks.

Add Comment