What causes "Tablet to be moved: [%v] is not being served" in dgraph-io/dgraph?

Re-check /state to confirm the predicate is currently being served and by which group

Tablet to be moved: [%v] is not being served

Error message

Tablet to be moved: [%v] is not being served

What it means

movePredicate re-checks Zero's membership map with s.ServingTablet(predicate) before starting the move. If no tablet entry exists for the predicate at move time, there is no source group and no data to stream, so it aborts with this error. Unlike error 121 this fires inside movePredicate, so it can also trigger from the automatic rebalancer when membership changes between choosing and moving a tablet.

Source

Thrown at dgraph/cmd/zero/tablet.go:152

		req.DstGroup)}, nil
}

// movePredicate is the main entry point for move predicate logic. This Zero must remain the leader
// for the entire duration of predicate move. If this Zero stops being the leader, the final
// proposal of reassigning the tablet to the destination would fail automatically.
func (s *Server) movePredicate(predicate string, srcGroup, dstGroup uint32) (err error) {
	s.moveOngoing <- struct{}{}
	defer func() {
		<-s.moveOngoing
	}()

	// Ensure that reserved predicates cannot be moved.
	if x.IsReservedPredicate(predicate) {
		return errors.Errorf("Unable to move reserved predicate %s", predicate)
	}
	tab := s.ServingTablet(predicate)
	if tab == nil {
		return errors.Errorf("Tablet to be moved: [%v] is not being served", predicate)
	}

	// Feed the outcome of this attempt back to the rebalancer, so it stops re-picking a tablet
	// whose moves keep failing.
	start := time.Now()
	defer func() {
		s.recordMoveResult(predicate, time.Since(start), err)
	}()

	timeout := moveTimeout(predicateMoveTimeout, tab)
	ctx, cancel := context.WithTimeout(context.Background(), timeout)
	defer cancel()

	span := trace.SpanFromContext(ctx)
	defer span.End()

	// Ensure that I'm connected to the rest of the Zero group, and am the leader.
	if _, err := s.latestMembershipState(ctx); err != nil {

View on GitHub (pinned to 759e242be6)

Solutions

Re-check /state to confirm the predicate is currently being served and by which group
If the predicate was intentionally dropped, do nothing — the error is expected
Retry the move after membership stabilizes if the predicate should exist
Avoid running moves concurrently with drop operations

Defensive patterns

Strategy: retry

Validate before calling

tablet_is_served() {
  curl -s localhost:6080/state | jq -e --arg p "$1" \
    '[.groups[].tablets // {} | keys[]] | index($p) != null' >/dev/null
}
tablet_is_served "$TABLET" || exit 0

Try / catch

for i in 1 2 3; do
  resp=$(curl -s "localhost:6080/moveTablet?tablet=$TABLET&dst_group=$DST")
  msg=$(echo "$resp" | jq -r .msg)
  [[ "$msg" == *"is not being served"* ]] && { sleep 10; continue; }
  break
done

Prevention

Don't run manual moves concurrently with DropAll/DropAttr operations
Re-read /state immediately before each move instead of caching membership
If the predicate was intentionally dropped, treat this error as expected

When it happens

Trigger: The predicate was dropped between tablet selection and the move; membership state changed so the predicate is no longer assigned; MoveTablet called with a predicate not in the serving map (e.g. race with DropAll/DropAttr); rebalancer picked a stale tablet entry.

Common situations: Running manual moves concurrently with schema drops or data deletions; rebalancer racing with cluster membership churn; moving a predicate on a group whose Alphas just lost leadership and re-registered without the tablet.

Related errors

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