Summary
Shard.vectorQueueLenght is misspelled — Lenght for Length — in both the @SerializedName and the record component. The server sends vectorQueueLength, so the field never binds and the value is always 0, on every server version. Nothing throws and nothing is logged.
Where it comes from
io/weaviate/client6/v1/api/cluster/Shard.java (6.3.1):
public record Shard(
@SerializedName("name") String name,
@SerializedName("class") String collection,
@SerializedName("objectCount") int objectCount,
@SerializedName("vectorIndexingStatus") VectorIndexingStatus vectorIndexingStatus,
@SerializedName("vectorQueueLenght") int vectorQueueLenght, // <-- here, twice
@SerializedName("compressed") boolean compressed,
@SerializedName("loaded") boolean loaded,
@SerializedName("numberOfReplicas") int numberOfReplicas,
@SerializedName("replicationFactor") int replicationFactor) {}
The server's own model, entities/models/node_shard_status.go:61:
VectorQueueLength int64 `json:"vectorQueueLength"`
Empirical confirmation
GET /v1/nodes?output=verbose against Weaviate 1.39.0 — the key the server actually emits, and the one the client looks for:
shard keys: ['asyncReplicationStatus', 'class', 'compressed', 'loaded', 'name',
'numberOfReplicas', 'objectCount', 'replicationFactor',
'vectorIndexingStatus', 'vectorQueueLength']
vectorQueueLength = 0 <- present
vectorQueueLenght = None <- what the client asks for; not there
Because Gson leaves an unmatched field at its default, a shard with a queue of 42 deserializes to vectorQueueLenght() == 0. The value is only interesting while async indexing is catching up, which is exactly when it reads as zero.
Suggested fix
Rename the JSON key and the record component to vectorQueueLength.
No @SerializedName(alternate = …): unlike #607, nothing was ever validly stored or sent under the misspelling, so there is no old spelling to stay compatible with.
Also on this record, not fixed here
Two adjacent gaps in the same Shard, worth their own tickets if you agree they are bugs:
objectCount, numberOfReplicas, replicationFactor and vectorQueueLength are int64 on the server and int here.
- The server sends
asyncReplicationStatus and Shard has no component for it, although io/weaviate/client6/v1/api/cluster/AsyncReplicationStatus.java exists and is currently unreferenced.
Version
- java-client 6.3.1 (present since
Shard was introduced)
- Weaviate 1.39.0
Summary
Shard.vectorQueueLenghtis misspelled —LenghtforLength— in both the@SerializedNameand the record component. The server sendsvectorQueueLength, so the field never binds and the value is always0, on every server version. Nothing throws and nothing is logged.Where it comes from
io/weaviate/client6/v1/api/cluster/Shard.java(6.3.1):The server's own model,
entities/models/node_shard_status.go:61:Empirical confirmation
GET /v1/nodes?output=verboseagainst Weaviate 1.39.0 — the key the server actually emits, and the one the client looks for:Because Gson leaves an unmatched field at its default, a shard with a queue of 42 deserializes to
vectorQueueLenght() == 0. The value is only interesting while async indexing is catching up, which is exactly when it reads as zero.Suggested fix
Rename the JSON key and the record component to
vectorQueueLength.No
@SerializedName(alternate = …): unlike #607, nothing was ever validly stored or sent under the misspelling, so there is no old spelling to stay compatible with.Also on this record, not fixed here
Two adjacent gaps in the same
Shard, worth their own tickets if you agree they are bugs:objectCount,numberOfReplicas,replicationFactorandvectorQueueLengthareint64on the server andinthere.asyncReplicationStatusandShardhas no component for it, althoughio/weaviate/client6/v1/api/cluster/AsyncReplicationStatus.javaexists and is currently unreferenced.Version
Shardwas introduced)