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

  1. Retry the Connect call with a fresh, longer-lived context (context.Background() or a generous timeout).
  2. Check Zero's health/log for contention or laggard membership updates; restart or scale Zero if it is stuck holding connectLock.
  3. Verify network latency between alpha and Zero; increase client gRPC timeout settings.
  4. 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

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


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