Last modified: 2013-04-22 16:17:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T43990, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41990 - API Edit conflict despite no one is editing with appendtext when editing through redirect
API Edit conflict despite no one is editing with appendtext when editing thro...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Brad Jorsch
: code-update-regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-10 23:27 UTC by Rainer Rillke @commons.wikimedia
Modified: 2013-04-22 16:17 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rainer Rillke @commons.wikimedia 2012-11-10 23:27:02 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
Comment 1 Rainer Rillke @commons.wikimedia 2012-11-10 23:32:59 UTC
It seems to be related to the fact that all these pages where it happens are redirects
Comment 2 Rainer Rillke @commons.wikimedia 2012-11-10 23:34:42 UTC
Since this never happened before adding keyword "code-update-regression"
Comment 3 Brad Jorsch 2012-11-12 05:52:29 UTC
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.
Comment 4 Alex Monk 2012-11-12 17:19:40 UTC
Merged by Reedy. Looks like he deployed it at about 15:30. Is this fixed now?
Comment 5 Rainer Rillke @commons.wikimedia 2012-11-13 08:14:48 UTC
Works. Thanks.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links