https://bugzilla.wikimedia.org/show_bug.cgi?id=35786
Web browser: ---
Bug #: 35786
Summary: usercontribs ucstart returned from api may result in
overlapping result sets
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: API
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: ar...@wikimedia.org
CC: bryan.tongm...@gmail.com, roan.katt...@gmail.com,
s...@reedyboy.net, soxre...@gmail.com
Classification: Unclassified
Mobile Platform: ---
Version of MW: 1.20-xxx and probably as far back as usercontribs is available
in the API
Because a bot or possibly a script-assisted user may edit more than once a
second, use of the ucstart parameter returned in <query-continue> tags to
retrieve the next bach of changes may retrieve some changes already seen in the
previous batch. For example, see below:
zh.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=Liangent-bot&ucstart=2012-04-07T07:44:45Z
This returns ucstart of 2012-04-07T07:44:44Z but some of those changes are
already in the current result set. Retrieving the new url gets some dups:
http://zh.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=Liangent-bot&ucstart=2012-04-07T07:44:44Z
Suggested fix: add a revision id or other tag from what would be the first row
of the new result set, to the end of the parameter in these cases:
ucstart="2012-04-07T07:44:43Z|20655891"
The revid is risky if the revision is hidden or deleted by the time the new
result set is requested; perhaps there's some better unique tag that can be
tacked on to the parameter instead.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- 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
