https://bugzilla.wikimedia.org/show_bug.cgi?id=63865
Brad Jorsch <bjor...@wikimedia.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Brad Jorsch <bjor...@wikimedia.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
