[sokra]

Summary

This retries vercel deploy when it fails with a transient network error before the CLI reports a deployment. It is the third of three stacked PRs.

Why. On v16.5.0-canary.6 attempt 1 (example), vercel deploy printed Error: fetch failed and no deployment URL. The harness failed straight away; the cause it reported was a misleading Invalid URL.

When it retries. All of these must hold:

• vercel deploy exits non-zero;
• stdout isn't a URL, and the output (with ANSI codes stripped) has no Inspect/Preview/Production URL line;
• the output has a CLI Error: line with a network failure: fetch failed, ECONNRESET, ETIMEDOUT, EAI_AGAIN, ECONNREFUSED, UND_ERR_SOCKET, UND_ERR_CONNECT_TIMEOUT or socket hang up;
• the output doesn't contain an auth or build diagnostic (Unauthorized, Forbidden, Build failed, Command "…" exited, …).

Limits.

• At most 3 attempts in total, waiting 5 s and then 10 s between them.
• It only retries while at least 60 s of the setup budget would remain after the wait.
• Every other failure goes through the existing throwDeploymentError path unchanged, with no extra deploy.

Accepted risk. If the connection drops after Vercel accepted the upload, a retry can leave an orphaned preview deployment (the harness deploys with --force). That's at most 2 extra previews per suite start in the test project. The retry log line says so and includes the CLI output.

This PR also fixes a typo in a comment in test/e2e/app-dir/resume-data-cache/resume-data-cache.test.ts. That change is there so Test new and changed tests when deployed runs a deploy-mode suite against the full stack.

Verification

• pnpm jest test/unit/next-deploy-failure: 43/43 pass.
  • Retries: retry-then-succeed, giving up after 3 calls, and skipping the retry when too little budget is left.
  • No retry (exactly one deploy): auth error, build failure, a network error after a URL or an Inspect line (including ANSI-colored output), a build diagnostic that mentions fetch failed, and Unauthorized next to fetch failed.
• prettier, eslint and pnpm typescript are clean.
• Not run: a real Vercel deployment (the sandbox has no test credentials).

[github-actions]

Tests Passed

Commit: 81261a8

[vercel-fleet-prod]

Deploy-mode CI validation

I fixed a typo in a comment in test/e2e/app-dir/resume-data-cache/resume-data-cache.test.ts (b6a16ff) so that Test new and changed tests when deployed would run a deploy-mode suite with the full stack (polling + diagnostics + deploy retry).

Job	Suite	Result
Test new and changed tests when deployed (1/5)	resume-data-cache.test.ts	✅ passed in 81.9s
Test new and changed tests when deployed (cache components) (1/5)	resume-data-cache.test.ts	✅ passed in 76.7s

Log excerpts from the regular job:

NEXT_TEST_VERSION=https://vercel-packages.vercel.app/next/commits/b6a16ffdb99b4551c5d5aa81627158c7e2e1700c/next
Starting test/e2e/app-dir/resume-data-cache/resume-data-cache.test.ts retry 0/0
test/e2e/app-dir/resume-data-cache/resume-data-cache.test.ts finished on retry 0/0 in 81.91s

What this shows: with the deploy retry wrapper applied, vercel deploy still succeeds on a real deployment from this commit's preview tarball. The IDs are then extracted from the build logs and the suite passes. The wrapper doesn't break the normal single-attempt path, and the suite didn't time out.

What it can't show: the retry only fires on a CLI Error: network line before any deployment URL appears, which a healthy run never produces. It's covered by the unit tests in test/unit/next-deploy-failure (43/43): retry on fetch failed/ECONNRESET/ETIMEDOUT, no retry once a URL was reported or for auth/build errors, and the attempt cap. Also, run-tests.js hides the output of passing suites (hideOutput unless --debug), so a passing job log doesn't include the harness log lines, including any retry line.