Page MenuHomePhabricator

Pywikibot does not honor API etiquette regarding dispatch
Closed, ResolvedPublic


"[Bots] should check before editing entities (but only every 60s) if the Median on Special:DispatchStats (also available via API as median) is 60 or higher and not edit."

This appears to only be relevant to Wikibase, as the statistics for en.wp does not include the dispatch entry.

Event Timeline

jayvdb raised the priority of this task from to Needs Triage.
jayvdb updated the task description. (Show Details)
jayvdb subscribed.

What have bots to do in that case? Is I see the special page is available on wikibase only. We may

  • throttle wikibase edits
  • throttle edits when the client is affected which is listed with the median lag
  • throttle edits on the Client itself

We may throttle edits by

  • freshest lag
  • median lag
  • one minute
  • other delay e.g. increase the the retry_wait

but what should we do when the median lag is still higher than 60? Process the current edit and wait for the next delay number?

Xqt triaged this task as High priority.Jul 30 2017, 1:27 PM

json call sample:

{'batchcomplete': '',
 'query': {'statistics': {'activeusers': 18695,
                          'admins': 55,
                          'articles': 29901177,
                          'dispatch': {'average': {'lag': 297,
                                                   'pending': 2421},
                                       'freshest': {'lag': 7,
                                                    'pending': 76,
                                                    'position': '526031830',
                                                    'site': 'ruwikibooks',
                                                    'touched': '2017-07-30T13:03:48Z'},
                                       'median': {'lag': 67,
                                                  'pending': 659,
                                                  'position': '526031247',
                                                  'site': 'svwikiversity',
                                                  'touched': '2017-07-30T13:02:48Z'},
                                       'newest': {'id': 526031906,
                                                  'timestamp': '20170730130355'},
                                       'oldest': {'id': 523931085,
                                                  'timestamp': '20170727130005'},
                                       'stalest': {'lag': 117327,
                                                   'pending': 889773,
                                                   'position': '525142133',
                                                   'site': 'enwiki',
                                                   'touched': '2017-07-30T13:02:17Z'}},
                          'edits': 529143615,
                          'images': 0,
                          'jobs': 704269,
                          'pages': 31604526,
                          'queued-massmessages': 0,
                          'users': 2843589}}}

Due to T171263 this is maybe not the best moment to exactly implement what's written at Wikidata:Bots#Bot accounts, but on the long run this would be useful to have. According to the corresponding Grafana chart of the median lag (you need to select "median" from the legend manually), bots would not be allowed to edit at all since 2017-06-28, 21:30. At that time, the median lag suddenly rose from robust ~15 seconds to robust ~100 seconds, with only very little variation. The median lag did not even decrease when the stalest lag had caught up at around 21:30 on 2017-07-25.

We don't really know why the dispatcher cannot handle the edit rates at Wikidata since a couple of weeks. High edit rates likely play a role here, but with regards to the stable median lag chart I would be surprised if that was the only or main reason. My impression is that there is no way to have a median dispatch lag lower than 60 seconds with the current configuration. In order not to shut down all (Pywikibot) Wikidata bots completely, we should wait for a solution of T171263 before this one is implemented.