lefarcenandGitHub 36a9dcc93b fix(release): retry R2 storage uploads on transient ECONNRESET/5xx (#4107) ...

* fix(release): retry R2 storage uploads on transient ECONNRESET/5xx

Nightly mac intel x64 has been failing repeatedly at the
publish-platform step with `[TypeError: fetch failed] ECONNRESET`.
The storage helper PUTs each release artifact (the intel DMG + ZIP,
the largest payloads) as a single fetch with zero retry, so one
mid-transfer TLS reset on the longest-lived connection kills the whole
release job. arm64/win share the script but their shorter uploads dodge
the blip — pure structural flakiness, not a size cap.

Wrap the PUT and GET paths in signedFetchWithRetry: up to 5 attempts
with exponential backoff + jitter, retrying on network throw
(ECONNRESET et al.) and 429/5xx, while passing 4xx (e.g. 412
precondition used by beta version reservation) straight through. Each
attempt re-signs with a fresh x-amz-date so the SigV4 signature never
goes stale across a backoff.

* fix(release): recover own beta lock on ambiguous-success 412

Retrying the conditional `if-none-match: *` reservation PUT is not
idempotent: a transient reset (the exact failure the retry recovers
from) can drop the response after R2 already created THIS run's lock,
and the retried PUT then sees 412. The old code read every 412 as
"reserved by a peer", so it would skip to the next beta number (leaking
an owned reservation) or, under manual override, fail the release.

On 412, read the lock back and accept it when this run owns it
(validateVersionReservation: same repo/workflow/runId/commit). Only a
lock owned by a different run is a real collision that skips forward.

Addresses review feedback on the upload-retry change.

2026-06-10 15:40:16 +00:00

..

release

fix(release): retry R2 storage uploads on transient ECONNRESET/5xx (#4107)

2026-06-10 15:40:16 +00:00