Arcstur added a comment.
Hello, everyone, I'll share here some info regarding QS3 so you can help me understand if we are or not respecting it... I'll split it into parts. 1. QS3 does not deal with maxlag directly because it does not use the Action API, only the Wikibase REST API. 2. QS3 will sometimes hit 429 in the REST API, when that happens, it starts an exponential backoff wait using the python urllib library. We are frequently hitting 90 edits per minute, which is the maximum allowed for the users. We are not editing more than that because that is not possible. The edits per minute can be checked in EditGroups for some batches. 3. In January a lot of users came to me warning that batches were stalling for hours. They were regularly being stalled for 1h+. After debugging I saw that the "Retry-After" header sent with the 429 had enormous delay times, up to 6 hours. So I modified QS3 to start ignoring that and use just the timeout with exponential backoff: https://github.com/wikimediabrasil/quickstatements3/issues/409 Without a good way to measure if maxlag is being respected or not is hard to tell. Also, why we define it in terms of maxlag instead of terms properly defined by HTTP requests? About (3), I can switch back for QS3 to use the Retry-After header received with 429's, but if that makes batches stall for 1h+, which is unreasonble since every user has 90 edits per minute per default. TASK DETAIL https://phabricator.wikimedia.org/T421642 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
_______________________________________________ pywikibot-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
