Last modified: 2013-04-22 16:17:18 UTC
Introduction: 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. -REQUEST PARAMS: 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 -REQUEST HEADERS: 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 -RESPONSE TEXT: {"servedby":"mw73","error":{"code":"editconflict","info":"Edit conflict detected"}} -RESPONSE HEADERS: 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: mw73 srv292 srv290 srv252 srv256 srv299 srv257 mw65 mw68 srv294
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.