Client network socket disconnected before secure TLS connection was established

TL;DR

We often see our CI fail on this action with the seemingly ephemeral error:

Client network socket disconnected before secure TLS connection was established

Expected behavior

The action to be able to reliably authenticate with Google even in the presence of network errors.

Observed behavior

The action fails seemingly randomly.

Action YAML

Here is how we use the action: https://github.com/firezone/firezone/blob/main/.github/actions/gcp-docker-login/action.yml

It is used by many workflows, for example: https://github.com/firezone/firezone/blob/main/.github/workflows/_integration_tests.yml

Log output

https://github.com/firezone/firezone/actions/runs/15918683976/job/44901141278

Additional information

No response

@thomaseizinger

Hi there @thomaseizinger 👋!

Thank you for opening an issue. Our team will triage this as soon as we can. Please take a moment to review the troubleshooting steps which lists common error messages and their resolution steps.

@thomaseizinger

Hi @thomaseizinger - thanks for opening an issue. This is definitely a new one for me. Are you by chance running on self-hosted runners (I'm not sure if ubuntu-22.04-xlarge is a GitHub-managed image or a custom one). I did some digging, and the most common cause appears to be a misbehaving proxy.

How often is this happening? If it only happened once, it also could have been a temporary issue the upstream API.

@thomaseizinger - thanks for opening an issue. This is definitely a new one for me. Are you by chance running on self-hosted runners (I'm not sure if ubuntu-22.04-xlarge is a GitHub-managed image or a custom one). I did some digging, and the most common cause appears to be a misbehaving proxy.

They are GitHub hosted runners but I believe I've seen this issue before too. Can't say for sure though.

How often is this happening? If it only happened once, it also could have been a temporary issue the upstream API.

We run a lot of CI jobs but I'd say at least 10 times in the last couple of days. Enough that it didn't seem like a once-off issue to me.

Could you enable debug output for the workflow for a few days and capture one of the failures with the debug logs on?

Just hit this again but it appears the debug logs don't contain much:

[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper] Starting process:
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   File name: '/home/runner/actions-runner/externals/node20/bin/node'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Arguments: '"/home/runner/work/_actions/google-github-actions/auth/ba79af03959ebeac9769e648f473a284504d9193/dist/main/index.js"'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Working directory: '/home/runner/work/firezone/firezone'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Require exit code zero: 'False'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Encoding web name:  ; code page: ''
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Force kill process on cancellation: 'False'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Redirected STDIN: 'False'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Persist current code page: 'False'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   Keep redirected STDIN open: 'False'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper]   High priority process: 'False'
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper] Updated oom_score_adj to 500 for PID: 2104.
[2025-06-30 12:46:51Z INFO ProcessInvokerWrapper] Process started with process id 2104, waiting for process exit.
[2025-06-30 12:46:52Z INFO ProcessInvokerWrapper] STDOUT/STDERR stream read finished.
[2025-06-30 12:46:52Z INFO ProcessInvokerWrapper] STDOUT/STDERR stream read finished.
[2025-06-30 12:46:52Z INFO ProcessInvokerWrapper] Finished process 2104 with exit code 1, and elapsed time 00:00:00.2216655.
[2025-06-30 12:46:52Z INFO CreateStepSummaryCommand] Step Summary file (/home/runner/work/_temp/_runner_file_commands/step_summary_29dbd6fe-0758-4255-9431-7cee09e303ca) is empty; skipping attachment upload
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Step result: Failed
[2025-06-30 12:46:52Z INFO ExecutionContext] Publish step telemetry for current step {
  "action": "google-github-actions/auth",
  "ref": "ba79af03959ebeac9769e648f473a284504d9193",
  "type": "node20",
  "stage": "Main",
  "stepId": "b9806369-4416-4b07-a47f-835efb3ad61d",
  "stepContextName": "login.auth",
  "isEmbedded": true,
  "hasPreStep": false,
  "hasPostStep": true,
  "errorMessages": []
}.
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Update job result with current composite step result 'Failed'.
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Processing embedded step: DisplayName='run'
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Initialize Env context for embedded step
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Evaluating: success()
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Result: false
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Skipping step due to condition evaluation.
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Processing embedded step: DisplayName='run'
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Initialize Env context for embedded step
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Evaluating: success()
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Result: false
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Skipping step due to condition evaluation.
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Processing embedded step: DisplayName='run'
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Initialize Env context for embedded step
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Evaluating: success()
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Result: false
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Skipping step due to condition evaluation.
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Processing embedded step: DisplayName='run'
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Initialize Env context for embedded step
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Evaluating: success()
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Result: false
[2025-06-30 12:46:52Z INFO CompositeActionHandler] Skipping step due to condition evaluation.
[2025-06-30 12:46:52Z INFO CreateStepSummaryCommand] Step Summary file (/home/runner/work/_temp/_runner_file_commands/step_summary_23f06c1b-75c3-4a87-94e8-3ebd41d335b8) is empty; skipping attachment upload
[2025-06-30 12:46:52Z INFO StepsRunner] Step result: Failed
[2025-06-30 12:46:52Z INFO ExecutionContext] Publish step telemetry for current step {
  "action": "./.github/actions/gcp-docker-login",
  "type": "composite",
  "stage": "Main",
  "stepId": "b9806369-4416-4b07-a47f-835efb3ad61d",
  "stepContextName": "login",
  "hasRunsStep": true,
  "hasUsesStep": true,
  "hasPreStep": false,
  "hasPostStep": true,
  "stepCount": 5,
  "result": "failed",
  "errorMessages": [
    "google-github-actions/auth failed with: error message: Failed to get ID Token. \n \n        Error Code : undefined\n \n        Error Message: Client network socket disconnected before secure TLS connection was established"
  ],
  "executionTimeInSeconds": 2,
  "startTime": "2025-06-30T12:46:50.4040124Z",
  "finishTime": "2025-06-30T12:46:52.1055644Z"
}.

I think I enabled the wrong debug logging ...

Here is a failed run with debug logs: https://github.com/firezone/firezone/actions/runs/15990853670/job/45103970949?pr=9735

Ah this is super helpful - that error is actually occurring before anything in our action runs:

This error message is coming from actions/toolkit, which is actually owned by GitHub. I could add some retry logic to attempt to try and fetch the ID token again, but there's not enough data to know if the error is even retryable. Can you open an issue upstream?

Thank you for diagnosing! Opened an upstream issue: actions/toolkit#2098

I could add some retry logic to attempt to try and fetch the ID token again, but there's not enough data to know if the error is even retryable.

It is a GET request so it should be safe to retry? It is embedded in a larger function call that appears to first create this URL though so I think it is hard to retry this from the outside.

I'll see if I can create a patch with a retry loop there and submit it as an upstream PR.

Add retries for getIDToken

Add retries for getIDToken (#502)

Thank you for fixing this!

Navigation Menu

Repository navigation

Client network socket disconnected before secure TLS connection was established #496

TL;DR

Expected behavior

Observed behavior

Action YAML

Log output

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Client network socket disconnected before secure TLS connection was established #496

Description

TL;DR

Expected behavior

Observed behavior

Action YAML

Log output

Additional information

Activity

github-actions commented on Jun 27, 2025

sethvargo commented on Jun 27, 2025

thomaseizinger commented on Jun 27, 2025

sethvargo commented on Jun 27, 2025

thomaseizinger commented on Jun 30, 2025

thomaseizinger commented on Jun 30, 2025

thomaseizinger commented on Jul 1, 2025

sethvargo commented on Jul 1, 2025

thomaseizinger commented on Jul 1, 2025

thomaseizinger commented on Jul 2, 2025

thomaseizinger commented on Aug 1, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions