When we stream the download and extraction of the CodeQL bundle, a network error such as ECONNRESET terminates the init Action rather than falling back to downloading the bundle before extracting it. This is because we never attached an error listener to the request returned by https.get, so follow-redirects emits the error as an unhandled error event, which is fatal. See #3367.

Attaching the listener is enough to turn the crash into the fallback path we already have. This PR also switches the pipe from the response into tar over to stream.pipeline, since tar.pipe(stdin).on("error", ...) only listens for errors on tar's standard input: an error on the response itself was unhandled, and would have left tar waiting indefinitely on a pipe that was never going to be closed. Finally, we abort the request if it stalls for five minutes so that a hung connection can't take the whole job with it.

I've deliberately not added a retry loop around the streaming attempt: toolcache.downloadTool, which we fall back to, already retries three times with exponential backoff and already avoids retrying non-transient status codes. The bug here was never that we don't retry, it's that we crashed before we got the chance.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: This only affects what happens when the streaming download fails, which currently means the job dies. Both new failure paths are covered by unit tests that were confirmed to fail without the fix.

Which use cases does this change impact?

Workflow types:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• Managed - Impacts users with dynamic workflows (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.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

• Unit tests - New tests simulate a mid-connection ECONNRESET and assert that we fall back rather than crashing.
• End-to-end tests - The existing bundle toolcache PR checks continue to exercise the streaming download on Linux.

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 - Streaming failures now surface as the existing fallback warning and show up in the download duration status field, rather than as a hard job failure.

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.