xtekky/gpt4free · error

download interrupted: %w

Error message

download interrupted: %w

What it means

downloadRuntime in g4f-go/download.go wraps copyWithProgress failures as 'download interrupted: %w'. The response body started streaming but the read/copy failed mid-transfer (connection reset, unexpected EOF, disk full on the .part file, or write errors to binDir/.g4f-runtime/runtime.download).

Source

Thrown at g4f-go/download.go:133

	defer resp.Body.Close()
	if resp.StatusCode != http.StatusOK {
		out.Close()
		os.Remove(partName(binDir))
		return fmt.Errorf("download failed: HTTP %s", resp.Status)
	}

	// Prefer Content-Length; fall back to manifest size.
	total := resp.ContentLength
	if total <= 0 {
		total = spec.Size
	}
	_, copyErr := copyWithProgress(out, resp.Body, total, start)
	if cerr := out.Close(); copyErr == nil {
		copyErr = cerr
	}
	if copyErr != nil {
		os.Remove(partName(binDir))
		return fmt.Errorf("download interrupted: %w", copyErr)
	}
	if err := os.Rename(partName(binDir), cachePath); err != nil {
		os.Remove(partName(binDir))
		return err
	}
	fmt.Printf("runtime: downloaded %s in %s\n", humanBytes(total), time.Since(start).Round(time.Second))

	if spec.Size > 0 {
		fi, err := os.Stat(cachePath)
		if err != nil {
			return err
		}
		if fi.Size() != spec.Size {
			return fmt.Errorf("size mismatch: got %d, expected %d (update runtime.json)", fi.Size(), spec.Size)
		}
	}
	return verifyRuntime(cachePath, spec)
}

View on GitHub (pinned to 973504e177)

Solutions

1. Free up disk space in binDir and confirm write permissions on the .g4f-runtime directory
2. Retry on a stable network — the partial .part file is cleaned up automatically, so the retry starts fresh
3. If a proxy kills idle connections, download spec.URL manually, place it at the expected cachePath (binDir/.g4f-runtime/runtime-<basename>), and re-run
4. Unwrap the %w cause to distinguish network resets from local write errors

Example fix

# before
# runtime: download interrupted: unexpected EOF

# after
# manual download into the cache location the tool checks
curl -L -o .g4f-runtime/runtime-runtime-linux-x64.tar.gz "<spec.URL>"
g4f  # reuses the cached archive

var stat syscall.Statfs_t
if err := syscall.Statfs(binDir, &stat); err == nil && stat.Bavail*uint64(stat.Bsize) < uint64(spec.Size)*3 {
    // not enough space for archive + extraction: fail fast
}

err := downloadRuntime(binDir, cachePath, spec)
if err != nil && strings.Contains(err.Error(), "download interrupted") {
    // backoff and retry; .part file is auto-cleaned so retry is safe
}

When it happens

Trigger: Long runtime downloads dropped mid-stream by NAT timeouts, flaky Wi-Fi, or proxy idle limits; disk full while writing the part file; the process's file descriptor or output stream (progress writer) failing.

Common situations: Large Python runtime archives on unstable links; mobile/tethered networks; CI runners with low disk quotas; antivirus locking the .part file on Windows.

Related errors

• download failed: %w
• All Antigravity endpoints failed. Last error: {last_error}
• Operation failed after {retries} attempts.
• download failed: HTTP %s
• size mismatch: got %d, expected %d (update runtime.json)

AI-assisted analysis of xtekky/gpt4free@973504e177 (2026-08-14). Data as JSON: /api/errors/37bd7aca5343bcb3. Report an issue: GitHub.