Change Details

When the quality constraints API is hit repeatedly mediawiki will flood the query service with requests, and the result will be mediawiki will get banned as in T163642. To avoid getting banned our requests should respect the header returned by the query service (suggested in T204267#4584397) **BDD** GIVEN a query service related constraint is run AND the query service sends a 429 response AND a "Retry-after" header is present THEN QualityConstraints should not run fresh constraint reports using the query service for that number of seconds **Links** 429 details: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 **Acceptance Criteria** - QualityConstraints looks at and respects the "Retry-after" header and 429 status - The Retry-after back off is used across all servers - If a 429 is received, a notice should be logged - if no retry-after is present, a warning should be logged --- General implementation breakdown: - [ ] write timestamp to cache when a 429 response is received - [ ] read from cache to check if we can make SPARQL requests or not The best cache to use is probably `ObjectCache::newAnything()`, so that the 429 protection will still work even if no cache is set up (falling back to the database). This should probably be wrapped up in some new class similar to the existing `ResultsCache`.

When the quality constraints API is hit repeatedly mediawiki will flood the query service with requests, and the result will be mediawiki will get banned as in T204267. To avoid getting banned our requests should respect the header returned by the query service (suggested in T204267#4584397) **BDD** GIVEN a query service related constraint is run AND the query service sends a 429 response AND a "Retry-after" header is present THEN QualityConstraints should not run fresh constraint reports using the query service for that number of seconds **Links** 429 details: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 **Acceptance Criteria** - QualityConstraints looks at and respects the "Retry-after" header and 429 status - The Retry-after back off is used across all servers - If a 429 is received, a notice should be logged - if no retry-after is present, a warning should be logged --- General implementation breakdown: - [ ] write timestamp to cache when a 429 response is received - [ ] read from cache to check if we can make SPARQL requests or not The best cache to use is probably `ObjectCache::newAnything()`, so that the 429 protection will still work even if no cache is set up (falling back to the database). This should probably be wrapped up in some new class similar to the existing `ResultsCache`.

When the quality constraints API is hit repeatedly mediawiki will flood the query service with requests, and the result will be mediawiki will get banned as in T163642T204267. To avoid getting banned our requests should respect the header returned by the query service (suggested in T204267#4584397) **BDD** GIVEN a query service related constraint is run AND the query service sends a 429 response AND a "Retry-after" header is present THEN QualityConstraints should not run fresh constraint reports using the query service for that number of seconds **Links** 429 details: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 **Acceptance Criteria** - QualityConstraints looks at and respects the "Retry-after" header and 429 status - The Retry-after back off is used across all servers - If a 429 is received, a notice should be logged - if no retry-after is present, a warning should be logged --- General implementation breakdown: - [ ] write timestamp to cache when a 429 response is received - [ ] read from cache to check if we can make SPARQL requests or not The best cache to use is probably `ObjectCache::newAnything()`, so that the 429 protection will still work even if no cache is set up (falling back to the database). This should probably be wrapped up in some new class similar to the existing `ResultsCache`.