dgraph-io/dgraph · warning
Context has error: %v
Error message
Context has error: %v
What it means
Zero's Connect RPC rejects a connection/membership request when the incoming gRPC context is already cancelled or timed out. The server checks ctx.Err() before doing any membership work and returns the wrapped context error to the client. It indicates the client's deadline expired or the connection was torn down before the RPC could be processed.
Source
Thrown at dgraph/cmd/zero/zero.go:514
}
if err := s.Node.proposeAndWait(ctx, zp); err != nil {
return nil, err
}
return &pb.Status{}, nil
}
// Connect is used by Alpha nodes to connect the very first time with group zero.
func (s *Server) Connect(ctx context.Context,
m *pb.Member) (resp *pb.ConnectionState, err error) {
// Ensures that connect requests are always serialized
s.connectLock.Lock()
defer s.connectLock.Unlock()
glog.Infof("Got connection request: %+v\n", m)
defer glog.Infof("Connected: %+v\n", m)
if ctx.Err() != nil {
err := errors.Errorf("Context has error: %v\n", ctx.Err())
return &emptyConnectionState, err
}
ms, err := s.latestMembershipState(ctx)
if err != nil {
return nil, err
}
// Ensure this Zero's own address in MembershipState reflects the current
// --my flag, even before ConfChangeUpdateNode has been committed through
// Raft. This prevents Alphas from receiving a stale address during the
// 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
}
}
View on GitHub (pinned to 759e242be6)
Solutions
- Retry the Connect call with a fresh, longer-lived context (context.Background() or a generous timeout).
- Check Zero's health/log for contention or laggard membership updates; restart or scale Zero if it is stuck holding connectLock.
- Verify network latency between alpha and Zero; increase client gRPC timeout settings.
- Ensure the client is not cancelling the context (e.g., request shutdown, probe timeout) before Connect completes.
Example fix
// before
ctx, cancel := context.WithTimeout(parentCtx, 200*time.Millisecond)
connState, err := zc.Connect(ctx, req)
// after
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
connState, err := zc.Connect(ctx, req)
if ctx.Err() != nil { /* retry with backoff */ } Defensive patterns
Strategy: retry
Validate before calling
if ctx.Err() != nil {
return fmt.Errorf("context already done before Connect: %w", ctx.Err())
} Try / catch
var cs *pb.ConnectionState
err := retry.Do(3, 2*time.Second, func() error {
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
var e error
cs, e = zc.Connect(ctx, req)
return e
}) Prevention
- Always pass a fresh context with a generous timeout to Connect; never reuse request-scoped contexts near cancellation.
- Monitor Zero for connectLock contention and slow membership updates.
- Set client gRPC keepalive and deadline settings appropriate to cluster size.
When it happens
Trigger: Calling Zero.Connect (used internally by dgraph alpha startup and by `dgraph zero` membership joins) with a context that has already been cancelled, or whose deadline expires while the request waits behind s.connectLock.
Common situations: Alpha startup with a short --dockerhal or default timeout while Zero is slow/busy; k8s liveness probes cancelling requests; client-side context deadlines set too low; a stalled Zero holding connectLock.
Related errors
- while calling MovePredicate
- NO_ADDR: No address provided: %+v
- Tablet predicate is empty in %+v
- recv final downstream(%d): %w
- connection string cannot be empty
AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01).
Data as JSON: /api/errors/a805c0101498db56.
Report an issue: GitHub.