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
- Set a unique external address for the dgraph server using --my=<host>:7080 (the internal gRPC server address).
- If invoking Connect programmatically, populate m.Addr before sending the request.
- Verify environment/hostname resolution in containers so the advertised address is non-empty.
- 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
- Always configure --my with a unique, reachable host:port on every alpha.
- Validate advertised address at startup and fail fast if empty.
- In containers, ensure hostname/IP resolution yields a non-empty address.
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
- REUSE_ADDR: Duplicate address to existing member: %+v. Self:
- connection string cannot be empty
- Move all tablets from group %d before removing the last node
- Context has error: %v
- REUSE_RAFTID: Duplicate Raft ID %d to removed member: %+v
AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01).
Data as JSON: /api/errors/0a1a8af6d30d8b36.
Report an issue: GitHub.