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 soView on GitHub (pinned to 75aa4b6d11)
Solutions
- Inspect the wrapped cause for the actual schema/activation failure.
- Verify the tenant exists and can transition to ACTIVE via /v1/schema/{class}/tenants.
- Grant the principal schema-write authorization for tenant activation.
- 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
- Check tenant status (ACTIVE/HOT) before batch imports.
- Use autoTenantActivation only when the writer can activate tenants.
- Grant schema-write RBAC to importing principals.
- Avoid leaving tenants in COLD state if they receive frequent writes.
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
- auto create tenants: %w
- error ensuring tenant active for write: %w
- role name uses a reserved operator prefix
- could not find index for class ${class}. It might have been
- multi-tenancy is not enabled
AI-assisted analysis of weaviate/weaviate@75aa4b6d11 (2026-09-04).
Data as JSON: /api/errors/25846699aa8dbe3c.
Report an issue: GitHub.