vitessio/vitess · error

GetTabletAliasesByCell(%v) failed: %w

Error message

GetTabletAliasesByCell(%v) failed: %w

What it means

deleteShardCell wraps any failure from GetTabletAliasesByCell when the ShardReplication object is missing for a cell, so it falls back to listing all tablets in the cell. The wrap includes the cell name and the underlying topo server error, indicating the per-cell tablet listing could not be read.

Source

Thrown at go/vt/vtctl/grpcvtctldserver/topo.go:147

	span.Annotate("keyspace", keyspace)
	span.Annotate("shard", shard)
	span.Annotate("cell", cell)
	span.Annotate("recursive", recursive)

	var aliases []*topodatapb.TabletAlias

	// Get the ShardReplication object for the cell. Collect all the tablets
	// that belong to the shard.
	sri, err := ts.GetShardReplication(ctx, cell, keyspace, shard)
	switch {
	case topo.IsErrType(err, topo.NoNode):
		// No ShardReplication object means that the topo is inconsistent.
		// Therefore we read all the tablets for that cell, and if we find any
		// in our shard, we'll either abort or try to delete them, depending on
		// whether recursive=true.
		aliases, err = ts.GetTabletAliasesByCell(ctx, cell)
		if err != nil {
			return fmt.Errorf("GetTabletAliasesByCell(%v) failed: %w", cell, err)
		}
	case err == nil:
		// If a ShardReplication object exists, we trust it to have all the
		// tablet records for the shard in that cell.
		aliases = make([]*topodatapb.TabletAlias, len(sri.Nodes))

		for i, node := range sri.Nodes {
			aliases[i] = node.TabletAlias
		}
	default:
		return fmt.Errorf("GetShardReplication(%v, %v, %v) failed: %w", cell, keyspace, shard, err)
	}

	// Get all the tablet records for the aliases we've collected. Note that
	// GetTabletMap ignores ErrNoNode, which is convenient for our purpose; it
	// means a tablet was deleted but is still referenced.
	tabletMap, err := ts.GetTabletMap(ctx, aliases, nil)
	if err != nil {

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Verify the topo server for that cell is reachable (vtctldclient GetTablets --cell <cell> or check vtgate/vtctld topo flags)
  2. Check the cell is registered: it must exist in the topo's cells list; re-add with vtctl AddCellInfo if missing
  3. If the topo is intentionally inconsistent, repair ShardReplication via topo repair commands (vtctl RepairShardReplication / prism repair) then retry DeleteShard
  4. Retry once the transient topo outage resolves; DeleteShard is idempotent for already-deleted tablets

Example fix

// before
cmd/vtctldclient DeleteShard --recursive ks/shard --cells=badcell
// after
vtctldclient GetTablets --cell badcell   # confirm topo connectivity first
vtctldclient DeleteShard --recursive ks/shard --cells=badcell
Defensive patterns

Strategy: validation

Validate before calling

// Check cell readability before DeleteShard
if _, err := ts.GetTabletAliasesByCell(ctx, cell); err != nil {
	return fmt.Errorf("cell %s unreadable, aborting DeleteShard: %w", cell, err)
}

Try / catch

if err := vtctldClient.DeleteShard(ctx, keyspace, shard); err != nil {
	if strings.Contains(err.Error(), "GetTabletAliasesByCell") {
		// topo/cell issue: verify cell and topo, then retry
	}
	return err
}

Prevention

When it happens

Trigger: Calling DeleteShard (vtctldserver) for a shard whose ShardReplication object is absent in a cell while GetTabletAliasesByCell(ctx, cell) fails due to a topo connection error, missing/misconfigured cell, or topo server outage.

Common situations: Topology server (etcd/zk) down or unreachable; cell name not registered in topo (wrong --cells_to_watch or stale cell config); topo data corrupted or manually deleted; running DeleteShard against a cell after a topo migration left it inconsistent.

Related errors

AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/5092afb6b31521b0. Report an issue: GitHub.