Last modified: 2014-05-06 10:23:40 UTC
Background: [[d:User_talk:Legoktm#I_requested_a_block_for_Legobot]] My bot was blocked for editing too fast and heavily increasing the lag for the dispatcher. Normally this wouldn't have been an issue on any other project since maxlag is all you need to worry about, except that on Wikidata has dispatcher lag. I think the best way to fix this going forwards would be to either: *Include dispatcher lag into maxlag *Make dispatch lag it's own thing (&dispatchlag=1000) For the time being, it would be nice if we could at least access the lag via the API, maybe in meta=siteinfo? (https://www.wikidata.org/w/api.php?action=query&meta=siteinfo&format=jsonfm) I personally think making it it's own parameter is the best, since the scale of dispatch lag is very different than maxlag, and that there's no need to stop "normal bots" (an archivebot, anything non-wikidata related) from editing if dispatcher lag is high, however if you include it in with maxlag, there's no need to update existing frameworks.
It's essentially a job queue like thing, so it should be in the statistics API module with the job queue. When your bot was blocked, the average dispatch lag was still below the usual one (around 10 hours, see bug 45892), so it's hard to say how this info could have helped the specific bot, or how a useful piece of information for bots could be produced. Probably the problem will be superseded when the system becomes more robust (bug 46643).
How does this play together with bug 46643? If it will be fixed, I guess we no longer have something like a dispatch lag (at least not one that can be easily measured or has much relevance)
The general premise of this bug is that bots need to be aware of dispatch lag, but there is no API for it. If bots no longer need to care about dispatch lag, then this can be closed as INVALID/WONTFIX.
Good point. We'll go for the other one.
