What causes "The server doesn't serve group id: %v" in dgraph-io/dgraph?

Send the delete request to an Alpha that serves the target group (check /state or the membership state to map group id to Alphas).

dgraph-io/dgraph · error

The server doesn't serve group id: %v

Error message

The server doesn't serve group id: %v

What it means

DeleteNamespace first checks that this Alpha actually serves the group named in the request (groups().ServesGroup). If not, it refuses to propose the namespace deletion and returns this error — the request must be routed to an Alpha in the group that owns the data.

Source

Thrown at worker/multi_tenancy.go:24

package worker

import (
	"context"
	"time"

	"github.com/golang/glog"
	"github.com/pkg/errors"
	"golang.org/x/sync/errgroup"

	"github.com/dgraph-io/dgraph/v25/conn"
	"github.com/dgraph-io/dgraph/v25/protos/pb"
	"github.com/dgraph-io/dgraph/v25/x"
)

func (w *grpcWorker) DeleteNamespace(ctx context.Context, req *pb.DeleteNsRequest) (*pb.Status, error) {
	var emptyRes pb.Status
	if !groups().ServesGroup(req.GroupId) {
		return &emptyRes, errors.Errorf("The server doesn't serve group id: %v", req.GroupId)
	}

	if err := groups().Node.proposeAndWait(ctx, &pb.Proposal{DeleteNs: req}); err != nil {
		return &emptyRes, errors.Wrapf(err, "Delete namespace failed for namespace %d on group %d",
			req.Namespace, req.GroupId)
	}
	return &emptyRes, nil
}

func ProcessDeleteNsRequest(ctx context.Context, ns uint64) error {
	// Update the membership state to get the latest mapping of groups to predicates.
	if err := UpdateMembershipState(ctx); err != nil {
		return errors.Wrapf(err, "Failed to update membership state while deleting namesapce")
	}

	state := GetMembershipState()
	g := new(errgroup.Group)

View on GitHub (pinned to 759e242be6)

Solutions

Send the delete request to an Alpha that serves the target group (check /state or the membership state to map group id to Alphas).
Verify the correct groupId for the namespace — namespace 0 (guardians) and tablet placement determine the owning group.
Re-run with the correct --alpha address of a node in the owning group.
Refresh stale client tooling/scripts that assume a fixed group id.

Example fix

// before
dgraph namespace del -x 2 -a "alpha-in-group-1:9080"
// after: target an alpha that serves group 2
dgraph namespace del -x 2 -a "alpha-in-group-2:9080"

Defensive patterns

Strategy: validation

Validate before calling

// resolve the group serving the namespace, pick an alpha from that group
state := getClusterState(zeroHTTPAddr)
alpha := pickAlphaForGroup(state, targetGroupId)
if alpha == "" { return errors.New("no alpha serves this group") }

Try / catch

_, err := wc.DeleteNamespace(ctx, req)
if err != nil && strings.Contains(err.Error(), "doesn't serve group id") {
    // re-target the request at an alpha in the owning group
}

Prevention

Check /state on Zero to map group ids to alpha addresses before multi-tenancy ops
Point namespace operations at an alpha in the group that owns the namespace's tablets
Avoid hardcoding group ids or alpha addresses in automation scripts

When it happens

Trigger: Calling Worker.DeleteNamespace (e.g. via dgraph namespace delete -a <alpha>) with a groupId this Alpha does not serve — the target namespace's tablets belong to a different group.

Common situations: Pointing the client at the wrong Alpha in a multi-group cluster; stale cluster topology assumptions after moves/rebalance; hardcoded group id in scripts; namespace moved to another group after a previous operation.

Related errors

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