What causes "error: failed to download new version: %v " in coreybutler/nvm-windows?

Verify connectivity to the update SourceURL (curl -L ) and check the status code manually.

error: failed to download new version: %v

Error message

error: failed to download new version: %v

What it means

nvm-windows' self-upgrade downloads the new release zip from update.SourceURL into a temp directory. This error means the HTTP GET for the main assets zip (e.g. nvm-noinstall.zip on GitHub) failed. The underlying %v is either a transport error (DNS, TLS, proxy, offline) or a non-200 status from the get() helper. Note this branch sends to a status channel rather than returning, so the goroutine continues with an empty body unless the caller aborts.

Source

Thrown at src/upgrade/upgrade.go:390

	} else {
		status <- Status{Text: "nvm is up to date", Done: true}
		return nil
	}

	// Make temp directory
	tmp, err := os.MkdirTemp("", "nvm-upgrade-*")
	if err != nil {
		status <- Status{Err: fmt.Errorf("error: failed to create temporary directory: %v\n", err)}
	}
	defer os.RemoveAll(tmp)

	// Download the new app
	source := update.SourceURL
	// source := fmt.Sprintf(update.SourceURL, update.Version)
	// source := fmt.Sprintf(update.SourceURL, "1.1.11") // testing
	body, err := get(source)
	if err != nil {
		status <- Status{Err: fmt.Errorf("error: failed to download new version: %v\n", err)}
	}

	os.WriteFile(filepath.Join(tmp, "assets.zip"), body, os.ModePerm)
	os.Mkdir(filepath.Join(tmp, "assets"), os.ModePerm)

	source = source + ".checksum.txt"
	body, err = get(source)
	if err != nil {
		return fmt.Errorf("error: failed to download checksum: %v\n", err)
	}

	os.WriteFile(filepath.Join(tmp, "assets.zip.checksum.txt"), body, os.ModePerm)

	filePath := filepath.Join(tmp, "assets.zip")                  // path to the file you want to validate
	checksumFile := filepath.Join(tmp, "assets.zip.checksum.txt") // path to the checksum file

	// Step 1: Compute the MD5 checksum of the file
	status <- Status{Text: "verifying checksum..."}

View on GitHub (pinned to 5b18223ca1)

Solutions

Verify connectivity to the update SourceURL (curl -L <SourceURL>) and check the status code manually.
If behind a proxy, set HTTPS_PROXY/HTTP_PROXY or configure the system proxy so the Go http.Client can use it.
Confirm the release asset actually exists at SourceURL (asset renamed or release marked pre-release/draft yields 404).
Re-run the upgrade; transient GitHub 5xx failures resolve themselves.
If it persists, download the nvm-noinstall.zip manually and replace the nvm root directory by hand.

Example fix

// before
body, err := get(source)
if err != nil {
    status <- Status{Err: fmt.Errorf("error: failed to download new version: %v\n", err)}
}

// after: stop the upgrade instead of continuing with an empty body
body, err := get(source)
if err != nil {
    status <- Status{Err: fmt.Errorf("error: failed to download new version: %v\n", err)}
    return err
}

Defensive patterns

Strategy: retry

Validate before calling

// Verify the update source is reachable before starting the upgrade
resp, err := http.Head(update.SourceURL)
if err != nil || resp.StatusCode != http.StatusOK {
    fmt.Println("update source unreachable; skipping self-upgrade:", err)
    return
}

Try / catch

In Go: treat any status-channel Err from the download phase as terminal — drain the channel, report, and do not let the goroutine continue with an empty body. Wrap with a bounded retry (e.g. 3 attempts, exponential backoff) for transport errors.

Prevention

Configure proxy env vars (HTTP_PROXY/HTTPS_PROXY) on restricted networks before upgrading.
Keep the machine online and DNS healthy; test with curl -L against the release URL.
Pin upgrades to stable release tags rather than latest.

When it happens

Trigger: Running 'nvm install' of a new nvm-windows release or the automatic update check when the machine cannot reach github.com / the release mirror; corporate proxy or TLS interception rejecting the request; the release URL in the update manifest pointing at a deleted/moved asset (HTTP 404); offline machine.

Common situations: Proxy-locked corporate networks blocking raw.githubusercontent/github releases; firewall or antivirus intercepting the download; a temporarily missing release asset after a GitHub release edit; DNS failure on offline CI agents.

Related errors

AI-assisted analysis of coreybutler/nvm-windows@5b18223ca1 (2026-08-15). Data as JSON: /api/errors/0651c8f72ad57c49. Report an issue: GitHub.