Change waitForProcessing to use exponential backoff by robertbrignull · Pull Request #3937 · github/codeql-action
The goal is to change waitForProcessing to backoff a bit more aggressively and reduce the maximum number of requests that it makes. During periods where analysis processing is being delayed, we're seeing a large number of extra GET requests that I believe are coming from here. See linked internal issue for more info.
In this PR I'm suggesting changing it to exponential backoff that'll make a maximum of 5 requests, instead of the current behaviour which can make up to 24 requests. I also add a wait before the first poll because processing will always take at least a couple of seconds so it's unlikely that an immediate poll will get anything. Let me know if you think this is reasonable. We can also tweak values to keep the maximum timeout to 2 minutes if that would be better.
Risk assessment
For internal use only. Please select the risk level of this change:
- Low risk: Hopefully can be safely tested before merge (either by tests or on a test repository)
Which use cases does this change impact?
Workflow types:
- Advanced setup - Impacts users who have custom CodeQL workflows.
- Managed - Impacts users with
dynamicworkflows (Default Setup, Code Quality, ...).
Products:
- Code Scanning - The changes impact analyses when
analysis-kinds: code-scanning. - Code Quality - The changes impact analyses when
analysis-kinds: code-quality. - Other first-party - The changes impact other first-party analyses.
- Third-party analyses - The changes affect the
upload-sarifaction.
Environments:
- Dotcom - Impacts CodeQL workflows on
github.comand/or GitHub Enterprise Cloud with Data Residency. - GHES - Impacts CodeQL workflows on GitHub Enterprise Server.
How did/will you validate this change?
- Test repository - This change will be tested on a test repository before merging.
- Unit tests - I am depending on unit test coverage (i.e. tests in
.test.tsfiles). - End-to-end tests - I am depending on PR checks (i.e. tests in
pr-checks).
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
- Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.
How will you know if something goes wrong after this change is released?
- Telemetry - I rely on existing telemetry or have made changes to the telemetry.
- Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
- Alerts - New or existing monitors will trip if something goes wrong with this change.
Are there any special considerations for merging or releasing this change?
- No special considerations - This change can be merged at any time.