With T144023 we introduced using 'retry-after' value from http response_headers.
But sometimes the maxlag value is very high compared to the retry_after value which might to short:
see https://api.travis-ci.org/v3/job/458291459/log.txt for example (T210322)
See also https://www.mediawiki.org/w/index.php?title=Manual:Maxlag_parameter&oldid=85948
Refer T172293 too.
Change 476274 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [bugfix] Increase the delay if maxlag >> retry-after
Getting a better estimate for Retry-After is T172293. This doesn't seem to really be a bug other than that existing feature request.
My path above is a proposal to use a portion of maxlag parameter as a prediction for the next lag if retry_after is far away from maxlag.
Change 476274 merged by jenkins-bot:
[pywikibot/core@master] [bugfix] Increase the delay if maxlag >> retry-after
Change #1354211 had a related patch set uploaded (by Xqt; author: Xqt):
[pywikibot/core@master] maxlag: Prefer maxlag over Retry-After for throttling delays#
The Retry-After value is always 5 seconds; there is a proposal in T172293 to change this. The recommendation in Manual:Maxlag parameter is to wait for the number of seconds specified in the maxlag error response. With the patch given above the wait cycle changes to this:
| retry_after | maxlag | old wait time | new wait time |
| 5 | 10 | 5 | 10 |
| 5 | 30 | 6 | 30 |
| 5 | 50 | 10 | 50 |
| 5 | 100 | 20 | 100 |
| 5 | 250 | 50 | 120 |
| 5 | 1000 | 120 | 120 |
| 5 | 5000 | 120 | 120 |