weaviate/weaviate · error

ensure tenant active: %w

Error message

ensure tenant active: %w

What it means

Wrapped error from addObjects when EnsureTenantActiveForWrite fails while the batch tries to activate tenant placeholders (autoTenantActivation enabled). The batch aborts because objects must land on an ACTIVE tenant.

Source

Thrown at usecases/objects/batch_add.go:123

		return nil, fmt.Errorf("auto create tenants: %w", err)
	}

	maxSchemaVersion = max(maxSchemaVersion, schemaVersion)

	// ensure tenants are active when AutoTenantActivation is enabled
	classTenants := make(map[string][]string)
	for _, obj := range objects {
		if obj.Tenant == "" {
			continue
		}
		classTenants[obj.Class] = append(classTenants[obj.Class], obj.Tenant)
	}
	for className, tenants := range classTenants {
		slices.Sort(tenants)
		tenants = slices.Compact(tenants)
		activationVersion, err := b.schemaManager.EnsureTenantActiveForWrite(ctx, className, tenants...)
		if err != nil {
			return nil, fmt.Errorf("ensure tenant active: %w", err)
		}
		maxSchemaVersion = max(maxSchemaVersion, activationVersion)
	}

	b.metrics.BatchTenants(tenantCount)
	b.metrics.BatchObjects(len(objects))
	b.metrics.BatchOp("total_preprocessing", beforePreProcessing.UnixNano())

	var res BatchObjects

	beforePersistence := time.Now()
	defer b.metrics.BatchOp("total_persistence_level", beforePersistence.UnixNano())

	if res, err = b.vectorRepo.BatchPutObjects(ctx, batchObjects, repl, maxSchemaVersion); err != nil {
		return nil, NewErrInternal("batch objects: %w", err)
	}

	// Reaggregate a unanimous limit-exceeded into a top-level error so

View on GitHub (pinned to 75aa4b6d11)

Solutions

  1. Inspect the wrapped cause for the actual schema/activation failure.
  2. Verify the tenant exists and can transition to ACTIVE via /v1/schema/{class}/tenants.
  3. Grant the principal schema-write authorization for tenant activation.
  4. Activate tenants explicitly before batch imports if autoTenantActivation keeps failing.

Example fix

// before
resp, err := client.Batch.ObjectsBatchCreate(ctx, batch) // fails on COLD tenant
// after
_, err := client.Schema().TenantsUpdater(ctx, className,
  []models.Tenant{{Name: t, ActivityStatus: models.TenantActivityStatusHOT}})
if err != nil { return err }
resp, err = client.Batch.ObjectsBatchCreate(ctx, batch)
Defensive patterns

Strategy: validation

Validate before calling

tenants, err := client.Schema().TenantsGetter(ctx, className)
if err != nil { return err }
for _, t := range tenants {
  if t.ActivityStatus == nil || *t.ActivityStatus != models.TenantActivityStatusACTIVE {
    return fmt.Errorf("tenant %s not active in %s", t.Name, className)
  }
}

Try / catch

err := batch(ctx, objects)
if err != nil && strings.Contains(err.Error(), "ensure tenant active") {
  activateTenants(ctx, className, tenants) // explicit activation then retry
}

Prevention

When it happens

Trigger: Batch import with autoTenantCreation and autoTenantActivation against a collection where activation of the just-created (or existing COLD) tenant fails — schema update rejected, auth failure, or context deadline exceeded.

Common situations: Writing to tenants left in COLD status where auto-activation cannot complete; cluster lag where activation cannot propagate; RBAC principal missing rights to mutate tenant status.

Related errors


AI-assisted analysis of weaviate/weaviate@75aa4b6d11 (2026-09-04). Data as JSON: /api/errors/25846699aa8dbe3c. Report an issue: GitHub.