dgraph-io/dgraph · error

NO_ADDR: No address provided: %+v

Error message

NO_ADDR: No address provided: %+v

What it means

Zero's Connect RPC requires the member to advertise its address. If the Connection request has an empty Addr field, Zero cannot register the node in the membership state and rejects it with the NO_ADDR prefix. This is a client-side request-construction bug or misconfiguration.

Source

Thrown at dgraph/cmd/zero/zero.go:543

	// brief window between restart and reconciliation.
	myAddr := s.Node.RaftContext.Addr
	if myId := s.Node.Id; myAddr != "" {
		if z, ok := ms.GetZeros()[myId]; ok && z.GetAddr() != myAddr {
			z.Addr = myAddr
		}
	}

	if m.ClusterInfoOnly {
		// This request only wants to access the membership state, and nothing else. Most likely
		// from our clients.
		cs := &pb.ConnectionState{
			State:      ms,
			MaxPending: s.orc.MaxPending(),
		}
		return cs, err
	}
	if m.Addr == "" {
		return &emptyConnectionState, errors.Errorf("NO_ADDR: No address provided: %+v", m)
	}

	for _, member := range ms.Removed {
		// It is not recommended to reuse RAFT ids.
		if member.GroupId != 0 && m.Id == member.Id {
			return &emptyConnectionState, errors.Errorf(
				"REUSE_RAFTID: Duplicate Raft ID %d to removed member: %+v", m.Id, member)
		}
	}

	numberOfNodes := len(ms.Zeros)
	for _, group := range ms.Groups {
		for _, member := range group.Members {
			switch {
			case member.Addr == m.Addr && m.Id == 0:
				glog.Infof("Found a member with the same address. Returning: %+v", member)
				conn.GetPools().Connect(m.Addr, s.tlsClientConfig)
				return &pb.ConnectionState{

View on GitHub (pinned to 759e242be6)

Solutions

  1. Set a unique external address for the dgraph server using --my=<host>:7080 (the internal gRPC server address).
  2. If invoking Connect programmatically, populate m.Addr before sending the request.
  3. Verify environment/hostname resolution in containers so the advertised address is non-empty.
  4. Restart the node with correct flags; check `dgraph alpha --my` value appears in Zero's /state output.

Example fix

// before
dgraph alpha --zero=z1:5080 // --my defaults/resolves to empty

// after
dgraph alpha --zero=z1:5080 --my=alpha1:7080
Defensive patterns

Strategy: validation

Validate before calling

if m.Addr == "" {
    return fmt.Errorf("refusing Connect: member %+v has no advertised address (--my)", m)
}

Try / catch

cs, err := zc.Connect(ctx, m)
if err != nil && strings.HasPrefix(err.Error(), "NO_ADDR") {
    return fmt.Errorf("set --my=<host>:7080 on the dgraph server and retry: %w", err)
}

Prevention

When it happens

Trigger: Calling Connect with &pb.Member{Id: X} but Addr left as ""; alpha started in a way that cannot determine its own advertised address (missing/blank --my or --addr flags).

Common situations: Docker/Kubernetes deployments where the my address is unset or resolves to empty; custom tooling invoking the Zero gRPC API directly without setting Addr; hostname resolution failures leaving Addr blank.

Related errors


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