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/
55.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=querylist=usercontribsucprop=ids|timestampucuser=ClueBot%20NGucstart=2014-04-14T15:03:47Zuclimit=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=querylist=usercontribsucprop=ids|timestampucuser=Anomie|ClueBot%20NGucstart=2014-04-14T15:03:47Zuclimit=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
