Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

v6: tenant updates are not split at the server's 100-tenant limit, so activate/deactivate fails above 100

Aperta Adatta ai principianti
  • Qualcosa non va?
#615 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@dudanogueira ci sta già lavorando.

Dal 28/8/2026.

  • #616 di @dudanogueira — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
84/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
api

Direzione di ricerca

Inizia da io/weaviate/client6/v1/api/collections/tenants/WeaviateTenantsClient.java, in particolare da update(List) e dai suoi chiamanti activate/deactivate. Controlla i test esistenti del client dei tenant e verifica che gli aggiornamenti con più di 100 elementi vengano inviati in batch, mentre create rimanga senza limiti; conferma che gli errori vengano propagati in modo coerente se un batch successivo ha esito negativo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

WeaviateTenantsClient.update(List<Tenant>) sends every tenant it is given in one
PUT /v1/schema/{class}/tenants. Weaviate caps that request at 100 tenants, so any
update of more than 100 fails:

HTTP 422: PUT /v1/schema/MyCollection/tenants: maximum number of tenants allowed to be
updated simultaneously is 100. Please reduce the number of tenants in your request and
try again

activate(...) and deactivate(...) are affected too, since both delegate to update.

The Python and TypeScript clients both split this request at 100 internally, so the same
code written against either of them works and the Java one does not. That difference is
also a trap for anyone measuring the limit: probing with the Python client reports "4000 in
one request, no cap", because it is quietly measuring the client's own batching rather than
the server's behaviour.

Reproduction

var tenants = client.collections.use("MyCollection").tenants;

List<String> names = IntStream.rangeClosed(1, 101)
    .mapToObj(i -> "tenant-" + i)
    .toList();

tenants.create(names.stream().map(Tenant::active).toList());  // fine: creates are not capped
tenants.deactivate(names);                                    // HTTP 422

tenants.deactivate(names.subList(0, 100)) succeeds, which isolates the boundary.

Confirmed against Weaviate 1.39.0 at the REST layer as well, independently of the client:

PUT /v1/schema/{class}/tenants with 100 tenants -> 200
PUT /v1/schema/{class}/tenants with 101 tenants -> 422

Where the limit comes from

usecases/schema/tenant.go:

const ErrMsgMaxAllowedTenants = "maximum number of tenants allowed to be updated simultaneously is 100. ..."

func validateTenants(tenants []*models.Tenant, allowOverHundred bool) (validated []*models.Tenant, err error) {
	if !allowOverHundred && len(tenants) > 100 {
		err = uco.NewErrInvalidUserInput(ErrMsgMaxAllowedTenants)
		return validated, err
	}

AddTenants calls this with allowOverHundred=true and UpdateTenants with false, so
creating tenants is uncapped and only updating is limited. Any fix should keep that
asymmetry rather than chunking both.

What the other clients do

Python (weaviate/collections/tenants/executor.py, client 4.23.0):

UPDATE_TENANT_BATCH_SIZE = 100
...
batches = ceil(len(tenants) / UPDATE_TENANT_BATCH_SIZE)

TypeScript (src/collections/serialize/index.ts, client 3.14.0):

public static tenants<T, M>(tenants: T[], mapper: (tenant: T) => M): M[][] {
  const mapped = [];
  const batches = Math.ceil(tenants.length / 100);
  for (let i = 0; i < batches; i++) {
    const batch = tenants.slice(i * 100, (i + 1) * 100);
    mapped.push(batch.map(mapper));
  }
  return mapped;
}

In both, the split is applied on the update path only, and create passes the whole list
through — matching the server.

Where it is in the Java client

io/weaviate/client6/v1/api/collections/tenants/WeaviateTenantsClient.java (6.3.1):

public void update(List<Tenant> tenants) throws IOException {
  this.restTransport.performRequest(new UpdateTenantsRequest(tenants), UpdateTenantsRequest.endpoint(collection));
}

public void activate(List<String> tenants) throws IOException {
  update(tenants.stream().map(Tenant::active).toList());
}

public void deactivate(List<String> tenants) throws IOException {
  update(tenants.stream().map(Tenant::inactive).toList());
}

One performRequest for the whole list, and no chunking anywhere in the package.

Suggested fix

Split in update(List<Tenant>) at 100, so activate, deactivate and update are all
covered by the one change. Leave create alone.

Worth deciding explicitly what a partial failure means: with more than one request, a batch
can now fail after earlier batches have already been applied. Python and TypeScript both
leave the earlier batches applied and propagate the error.

Lingua principale
Java
Stelle
34
Fork
29
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di weaviate/java-client

Tutte le issue di weaviate/java-client

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.