Last modified: 2014-04-14 15:18:23 UTC
The uccontinue pattern for list=usercontribs does not match that of other types of calls to the API (e.g. prop=revisions). Expected behavior: A query of the type http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=<username>&format=jsonfm&uclimit=1 should return a result with one revision and a query-continue.usercontribs.uccontinue field. This uccontinue field can them be supplied to another query in order to get the next revision. (e.g. http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=YurikBot&format=jsonfm&uclimit=1&uccontinue=2006-09-12T17:54:43Z Actual behavior: A query of the type http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=<username>&format=jsonfm&uclimit=1 returns a result with one revision, but has a query-continue.usercontribs.ucstart field. (note the "ucstart" instead of the "uccontinue"). If the value of this "ucstart" is passed as a "uccontinue" value, it will not work as expected. E.g. http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=YurikBot&format=jsonfm&uclimit=1&uccontinue=2006-08-29T15:38:01Z returns the same revision as http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=YurikBot&format=jsonfm&uclimit=1 While there is an obvious work-around of passing the query-continue.usercontribs.ucstart field back as a ucstart parameter, this behavior is unexpected.
Also note that manually constructing a properly formatted uccontinue for queries of only one user results in the uccontinue parameter being ignored. E.g.: http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=YurikBot&uclimit=1&format=jsonfm&ucprop=ids returns the same revision as http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=YurikBot&uclimit=1&format=jsonfm&ucprop=ids&uccontinue=YurikBot|2006-09-12T17:54:43Z
(In reply to Aaron Halfaker from comment #0) > While there is an obvious work-around of passing the > query-continue.usercontribs.ucstart field back as a ucstart parameter, this > behavior is unexpected. That's exactly what you *should* be doing. Simply take whatever is inside the query-continue, and pass it back to the server. So if the key is named 'ucstart', you pass it back as 'ucstart'. http://lists.wikimedia.org/pipermail/mediawiki-api-announce/2014-April/000055.html was the most recent reminder email about this. Note that in that email, Anomie explains that the behavior for list=usercontribs will be changing to be more standardized :P
(In reply to Kunal Mehta (Legoktm) from comment #2) > (In reply to Aaron Halfaker from comment #0) > > > While there is an obvious work-around of passing the > > query-continue.usercontribs.ucstart field back as a ucstart parameter, this > > behavior is unexpected. > > That's exactly what you *should* be doing. Simply take whatever is inside > the query-continue, and pass it back to the server. So if the key is named > 'ucstart', you pass it back as 'ucstart'. That is correct. Closing this bug accordingly. > http://lists.wikimedia.org/pipermail/mediawiki-api-announce/2014-April/ > 000055.html was the most recent reminder email about this. Note that in that > email, Anomie explains that the behavior for list=usercontribs will be > changing to be more standardized :P Although the change is not for any reason to do with this bug. It's because continuation breaks if someone has made more than uclimit edits within the same second. For example, until Gerrit change #103589 is deployed to enwiki, the following query can't be successfully continued: https://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucprop=ids|timestamp&ucuser=ClueBot%20NG&ucstart=2014-04-14T15:03:47Z&uclimit=1 <?xml version="1.0"?> <api> <query-continue> <usercontribs ucstart="2014-04-14T15:03:47Z" /> </query-continue> <query> <usercontribs> <item userid="13286072" user="ClueBot NG" pageid="41270837" revid="604167818" parentid="601196221" timestamp="2014-04-14T15:03:47Z" /> </usercontribs> </query> </api> ClueBot NG made two edits at 2014-04-14T15:03:47Z, revid 604167818 and revid 604167816. With uclimit=1 only one of these is returned and the ucstart value for continuation is identical to that in the original query, meaning it'll return the same result again instead of actually continuing. The fix is to change the continuation value to include the revid, like "2014-04-14T15:03:47Z|604167816", so the API can know which of the two edits to continue with. But then we can't use ucstart as the continuation parameter anymore, so we change to using uccontinue. Note this same problem happens for the case that already uses uccontinue: https://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucprop=ids|timestamp&ucuser=Anomie|ClueBot%20NG&ucstart=2014-04-14T15:03:47Z&uclimit=1 <?xml version="1.0"?> <api> <query-continue> <usercontribs uccontinue="ClueBot NG|2014-04-14T15:03:47Z" /> </query-continue> <query> <usercontribs> <item userid="13286072" user="ClueBot NG" pageid="41270837" revid="604167818" parentid="601196221" timestamp="2014-04-14T15:03:47Z" /> </usercontribs> </query> </api> Again it'll just return the same result over and over because the "uccontinue" value doesn't uniquely identify which row to continue from. After Gerrit change #103589 the uccontinue would be "ClueBot NG|2014-04-14T15:03:47Z|604167816" which will work correctly.
