We are seeing a increase in the number of 429 we receive when communicating with the qit.woo.com domain.
When a 429 is triggered, all requests from GitHub.com to qit.woo.com are blocked for a period, so we can't really have these happening, as per convo on Slack.
This PR spaces out the requests that each test does, that would check if the test finished or not.
This PR mitigates 429 by adding a configurable polling interval, increasing the polling interval from 5-15 seconds to up to 60-90 seconds. It also makes it so that a wait happens on the first poll as well as to not dispatch the test and poll immediately.
This only applies when running tests with the --wait command.
Testing Instructions
Your CLI can be pointed either to Prod or Staging, it doesn't matter
Run a test with a poll interval of 10 seconds: QIT_POLL_INTERVAL=10 qit run:security --wait automatewoo -vvv
See that the polling requests are spaced out 10 seconds.
Change the interval to 30 seconds, see that the polling requests are spaced out 30 seconds.
Example screenshot with a polling interval set to 10 seconds
We are seeing a increase in the number of 429 we receive when communicating with the qit.woo.com domain.
When a 429 is triggered, all requests from GitHub.com to qit.woo.com are blocked for a period, so we can't really have these happening, as per convo on Slack.
This PR is a continuation of https://github.com/woocommerce/qit-cli/pull/185. After merging that and monitoring 429's, I saw some being triggered on the polling endpoints.
What's the difference between this PR and #185:
This PR mitigates 429 by adding a configurable polling interval, increasing the polling interval from 5-15 seconds to up to 60-90 seconds. It also makes it so that a wait happens on the first poll as well as to not dispatch the test and poll immediately.
This only applies when running tests with the
--waitcommand.Testing Instructions
QIT_POLL_INTERVAL=10 qit run:security --wait automatewoo -vvvExample screenshot with a polling interval set to 10 seconds