v2.24.0: no binaries published to cloud-sql-connectors bucket (all platforms 404, 4h+ after release)

[dandalf]

Bug Description

v2.24.0 was published on GitHub at 2026-07-24T17:03:24Z, but none of its platform binaries were uploaded to the cloud-sql-connectors bucket. As of 2026-07-24T21:19:53Z — 4h16m later — every artifact under cloud-sql-proxy/v2.24.0/ still returns 404, while the equivalent v2.23.0 objects are all present.

The container images are only partially published, which suggests the release pipeline stopped partway rather than merely lagging:

• present in gcr.io/cloud-sql-connectors/cloud-sql-proxy: 2.24.0, 2.24.0-alpine
• missing: 2.24.0-bookworm, and the floating 2.24 / 2.24-alpine / 2.24-bookworm tags
• for comparison, v2.23.0 has the full set (2.23, 2.23-alpine, 2.23-bookworm, 2.23.0, 2.23.0-alpine, 2.23.0-bookworm)

The practical effect is that the newest release cannot be installed via the documented binary-download path.

There is also a systemic aspect worth considering separately: GitHub release publication and bucket upload are not atomic, and nothing distinguishes "not uploaded yet" from "wrong URL" — no release assets are attached to the GitHub release, and no checksum files are published alongside the binaries. Any automation that resolves the newest v2.* tag from the GitHub API and then downloads the matching object breaks during such a window, with a bare 404 as its only signal.

Example code (or command)

for v in v2.24.0 v2.23.0; do
  for f in cloud-sql-proxy.linux.amd64 cloud-sql-proxy.linux.arm64 \
           cloud-sql-proxy.darwin.amd64 cloud-sql-proxy.darwin.arm64; do
    printf '%s/%-32s %s\n' "$v" "$f" "$(curl -s -o /dev/null -w '%{http_code}' -I \
      "https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/$v/$f")"
  done
done

Result:

v2.24.0/cloud-sql-proxy.linux.amd64      404
v2.24.0/cloud-sql-proxy.linux.arm64      404
v2.24.0/cloud-sql-proxy.darwin.amd64     404
v2.24.0/cloud-sql-proxy.darwin.arm64     404
v2.23.0/cloud-sql-proxy.linux.amd64      200
v2.23.0/cloud-sql-proxy.linux.arm64      200
v2.23.0/cloud-sql-proxy.darwin.amd64     200
v2.23.0/cloud-sql-proxy.darwin.arm64     200

Stacktrace

--2026-07-24 19:07:18--  https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.24.0/cloud-sql-proxy.linux.amd64
Resolving storage.googleapis.com (storage.googleapis.com)... 173.194.64.207, 172.253.155.207, ...
Connecting to storage.googleapis.com (storage.googleapis.com)|173.194.64.207|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2026-07-24 19:07:18 ERROR 404: Not Found.

Steps to reproduce?

1. Resolve the newest v2.* release tag from https://api.github.com/repos/GoogleCloudPlatform/cloud-sql-proxy/releases — currently v2.24.0.
2. Download the matching binary from https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.24.0/cloud-sql-proxy.linux.amd64.
3. Observe HTTP 404. Repeat with v2.23.0 and observe HTTP 200.

Environment

• Reproduced from a GCE VM in us-central1 and independently from macOS (Darwin 25.5.0) — same result, so it is not a caching or regional-edge artifact.
• Affected release: v2.24.0. Unaffected: v2.23.0 and earlier.
• Encountered while baking a VM image, where the install step resolves the newest v2 release and fetches the corresponding binary.

Additional Details

Workaround, for anyone else hitting this: the git tag is published immediately, so building from source yields the same version.

CGO_ENABLED=0 go install github.com/GoogleCloudPlatform/cloud-sql-proxy/v2@v2.24.0
# cloud-sql-proxy version 2.24.0

Two suggestions, both aimed at making the release atomic from a consumer's point of view:

1. Publishing a checksum file next to each binary would give automation a way to tell "artifacts not uploaded yet" apart from "wrong URL", and would let consumers verify what they downloaded. There are currently no .sha256 or .sig objects in the bucket.
2. Attaching the binaries as GitHub release assets would tie artifact availability to the release itself, so a resolved tag always has something behind it.

Possibly related but a different root cause: #463 was a malformed URL in the release notes rather than a missing upload.

[kgala2]

Hello @dandalf,

We experienced an issue during the publication step of the v2.24.0 release, which prevented the platform binaries from being uploaded. We are preparing a new release to address this and ensure all binaries are published.

I will update this ticket once the new Auth Proxy version is available