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.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| [bugfix] Increase the delay if maxlag >> retry-after | pywikibot/core | master | +10 -5 |
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