weaviate/weaviate · error
can not assign new nodes to shard %s, it didn't exist in the
Error message
can not assign new nodes to shard %s, it didn't exist in the new partitions
What it means
During unfreeze, GetPartitions succeeded but the resulting partitions map has no entry for the tenant's shard, so no new node assignment can be made. The tenant entry is nulled and this error is returned, leaving the tenant unfrozen-but-unassigned (operation aborted).
Source
Thrown at cluster/schema/meta_class.go:733
// unfreeze creates a process requests and add them in memory to compare it later when
// TenantProcessRequest comes.
// it keeps the requested state ACTIVE/INACTIVE in memory.
// it updates the tenant status to UNFREEZING in RAFT schema.
// NOTE: can make some of the requests nil.
func (m *metaClass) unfreeze(nodeID string, i int, req *command.UpdateTenantsRequest, p *sharding.Physical) error {
name := req.Tenants[i].Name
process := m.shardProcess(name, command.TenantProcessRequest_ACTION_UNFREEZING)
partitions, err := m.Sharding.GetPartitions(req.ClusterNodes, []string{name}, m.Class.ReplicationConfig.Factor)
if err != nil {
req.Tenants[i] = nil
return fmt.Errorf("get partitions: %w", err)
}
newNodes, ok := partitions[name]
if !ok {
req.Tenants[i] = nil
return fmt.Errorf("can not assign new nodes to shard %s, it didn't exist in the new partitions", name)
}
oldNodes := p.BelongsToNodes
p.Status = types.TenantActivityStatusUNFREEZING
p.BelongsToNodes = newNodes
newToOld := map[string]string{}
slices.Sort(newNodes)
slices.Sort(oldNodes)
for idx, node := range newNodes {
if idx >= len(oldNodes) {
// ignore new nodes if the replication factor increase
// and relay on replication client will replicate the data
// after it's downloaded
continue
}
newToOld[node] = oldNodes[idx]View on GitHub (pinned to 75aa4b6d11)
Solutions
- Verify the tenant still exists in the class's sharding state and that the class wasn't recreated; re-check with GetTenants
- Recompute/re-sync the sharding state across the cluster (schema manager rebuild or restore from a consistent snapshot)
- Delete and re-add the tenant if its shard is genuinely gone, accepting data implications for the offloaded (COLD) tenant
- Check node membership and replication factor consistency — GetPartitions output depends on req.ClusterNodes and the class replication config
Example fix
// before
clients.UpdateTenants(class, []Tenant{{Name: t, Status: HOT}}) // shard missing after class rebuild
// after
tenants, _ := clients.GetTenants(class)
if _, ok := tenants[t]; !ok { clients.AddTenants(class, []Tenant{{Name: t, Status: HOT}}) } else { clients.UpdateTenants(...) } Defensive patterns
Strategy: validation
Validate before calling
tenants, err := getTenants(class)
if _, ok := tenants[tenant]; !ok { return ErrTenantShardMissing } Type guard
func shardExists(partitions map[string][]string, tenant string) bool {
_, ok := partitions[tenant]
return ok
} Prevention
- Verify the tenant/shard still exists before unfreezing
- Avoid deleting tenants or recreating classes while tenants are frozen
- Re-sync sharding state across nodes before lifecycle operations
When it happens
Trigger: UpdateTenants unfreeze path where partitions[name] lookup misses — the shard disappeared from the recomputed sharding state, e.g. after sharding state corruption, tenant deletion racing unfreeze, or class recreation.
Common situations: Unfreezing a tenant whose shard was removed while frozen (tenant deleted, class rebuilt); mismatches between the sharding state snapshot used at freeze time and the current one; multi-node cluster where one node has stale schema state.
Related errors
- reading shard state: %w
- determine shard: %w
- %w: %q
- collection %q has no local shards
- owner node not found
AI-assisted analysis of weaviate/weaviate@75aa4b6d11 (2026-09-04).
Data as JSON: /api/errors/c64e675a6d21cf09.
Report an issue: GitHub.