fix(cluster): read the vector queue length the server actually sends

[dudanogueira]

Motivation

Shard asks Gson for vectorQueueLenght — Lenght for Length — in both the @SerializedName and the record component. The server sends vectorQueueLength:

// entities/models/node_shard_status.go:61
VectorQueueLength int64 `json:"vectorQueueLength"`

so the field never binds and the value is always 0, on every server version. Nothing throws and nothing is logged. It matters precisely when it is interesting: the queue is only non-zero while async indexing is catching up, which is exactly when the client reports zero.

Confirmed against a live Weaviate 1.39.0 — GET /v1/nodes?output=verbose:

shard keys: ['asyncReplicationStatus', 'class', 'compressed', 'loaded', 'name',
             'numberOfReplicas', 'objectCount', 'replicationFactor',
             'vectorIndexingStatus', 'vectorQueueLength']

Approach

Rename the JSON key and the record component to vectorQueueLength.

No @SerializedName(alternate = "vectorQueueLenght"), deliberately, and the reasoning is the one from #612 rather than #610: an alternate earns its place when data was stored under the old spelling and has to keep loading. Nothing ever wrote this key — the server has always sent vectorQueueLength — so an alternate would only preserve a spelling that never appeared on the wire.

Key areas for review

• Shard is read-only in practice (it is only ever deserialized from GET /nodes), so the component rename is the whole change. Worth confirming you agree it is not worth an alternate.
• The two adjacent gaps on this record are not touched here and are noted at the bottom of v6: Shard.vectorQueueLenght is misspelled, so the vector queue length is always 0 #619 — objectCount/numberOfReplicas/replicationFactor/vectorQueueLength are int64 server-side and int here, and the server's asyncReplicationStatus has no component although AsyncReplicationStatus.java exists and is unreferenced. Happy to file either as its own ticket if you class them as bugs.

Testing

Unit — one round-trip row in JSONTest.testCases() covering a shard with a non-zero queue, which exercises both test_serialize and test_deserialize.

Verified the test fails without the fix, in both directions:

expected:<..., vectorQueueLength=[42], compressed=false, ...> but was:<..., vectorQueueLength=[0], compressed=false, ...>
expected:<...NG","vectorQueueLeng[th]":42,"compressed":fa...> but was:<...NG","vectorQueueLeng[ht]":42,"compressed":fa...>

No integration test: Shard.vectorQueueLength is only non-zero mid-indexing, so an assertion on it against a container would be inherently racy. The wire key is what was wrong, and the round-trip row pins that deterministically.

Locally green: 384 unit tests.

Breaking changes

Shard's canonical constructor and its accessor change name — vectorQueueLenght becomes vectorQueueLength. Anything calling shard.vectorQueueLenght(), constructing Shard positionally by name, or destructuring it in a record pattern needs the new spelling. Since the old accessor could only ever return 0, any caller reading it was reading a constant.

Closes #619

🤖 Generated with Claude Code

https://claude.ai/code/session_01HNeKV7TAYZGDyT9agqJwUf

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[bevzzz]

Please remove all comments from this PR and trim the PR description to what is strictly relevant.