What causes "http fetch: %v" in dgraph-io/dgraph?

Verify the Alpha is running and reachable: curl http:// /health

http fetch: %v

Error message

http fetch: %v

What it means

fetchURL performs an HTTP GET against an internal admin endpoint (e.g. /health or /state on an Alpha) when collecting debug info. If the request fails at the transport level, the error is wrapped as 'http fetch: %v'. Non-200 status codes are handled separately, so this specifically means the request never completed.

Source

Thrown at dgraph/cmd/debuginfo/debugging.go:89

	out, err := os.Create(filePath)
	if err != nil {
		return fmt.Errorf("error while creating debug file: %s", err)
	}
	defer func() {
		out.Close()
	}()
	_, err = io.Copy(out, resp)
	return err
}

// fetchURL fetches a profile from a URL using HTTP.
func fetchURL(source string, timeout time.Duration) (io.ReadCloser, error) {
	client := &http.Client{
		Timeout: timeout,
	}
	resp, err := client.Get(source)
	if err != nil {
		return nil, fmt.Errorf("http fetch: %v", err)
	}
	if resp.StatusCode != http.StatusOK {
		defer func() {
			if err := resp.Body.Close(); err != nil {
				glog.Warningf("error closing body: %v", err)
			}
		}()
		return nil, statusCodeError(resp)
	}

	return resp.Body, nil
}

func statusCodeError(resp *http.Response) error {
	if resp.Header.Get("X-Go-Pprof") != "" &&
		strings.Contains(resp.Header.Get("Content-Type"), "text/plain") {
		if body, err := io.ReadAll(resp.Body); err == nil {
			return fmt.Errorf("server response: %s - %s", resp.Status, body)

View on GitHub (pinned to 759e242be6)

Solutions

Verify the Alpha is running and reachable: curl http://<alpha_addr>/health
Correct the --alpha_addr host/port (default is http://localhost:8080)
Check network/firewall rules between the debuginfo client and the Alpha, and use the right scheme (http vs https)
Retry after the cluster is healthy

Example fix

// before
dgraph debuginfo --alpha_addr localhost:9080  # gRPC port, not HTTP
// http fetch: ... connection refused
// after
dgraph debuginfo --alpha_addr localhost:8080

Defensive patterns

Strategy: retry

Validate before calling

addr := *alphaAddr
if _, err := net.DialTimeout("tcp", strings.TrimPrefix(strings.TrimPrefix(addr, "http://"), "https://"), 3*time.Second); err != nil {
    return fmt.Errorf("alpha %s unreachable: %v", addr, err)
}
// also sanity check: curl http://<alpha_addr>/health before dgraph debuginfo

Try / catch

// Go pattern for callers wrapping fetchURL
body, err := fetchURL(source, timeout)
if err != nil {
    var nerr net.Error
    if errors.As(err, &nerr) && nerr.Timeout() { /* retry with backoff */ }
    return fmt.Errorf("http fetch: %v", err)
}

Prevention

Confirm the Alpha is up (curl http://<alpha>/health) before dgraph debuginfo
Use the HTTP port (default 8080), not the gRPC port (9080), in --alpha_addr
Check firewall/security-group rules between client and Alpha
Match the scheme: use https:// if the Alpha serves TLS
Add retry with backoff around debuginfo collection in automation

When it happens

Trigger: Running `dgraph debuginfo --alpha_addr <addr>` when the Alpha is down, the address/port is wrong, the connection is refused/timed out, DNS fails, or TLS is required but http:// was used (or vice versa).

Common situations: Cluster stopped before collecting debug info, wrong --alpha_addr (default localhost:8080) in distributed setups, firewall blocking the port, or querying an HTTPS-only Alpha over plain HTTP.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/4eb8156651447b13. Report an issue: GitHub.