Corrected. The original report had this backwards: it claimed 28 classes used the wrong key. They are all correct. rerankers/NvidiaReranker.java — cited in the original as the good example — is the one broken class. Rewritten below with the evidence.
Summary
rerankers/NvidiaReranker.java sends the base URL as baseUrl. The reranker-nvidia module reads baseURL. The value is stored in the schema and then ignored, so reranking silently goes to the default NVIDIA endpoint rather than the configured one.
Every other module config in the client (28 classes across vectorizers, generative and CohereReranker) already uses baseURL and is correct.
Why baseURL is canonical
Modules read the key through BaseClassSettings.GetPropertyAsString, which bottoms out in a plain case-sensitive map lookup — usecases/modulecomponents/settings/class_settings_property_helper.go:
value := h.GetSettings(cfg)[name]
and every module passes "baseURL":
// modules/text2vec-cohere/ent/class_settings.go
return cs.BaseClassSettings.GetPropertyAsString("baseURL", DefaultBaseURL)
// modules/reranker-nvidia/config/class_settings.go
return cs.propertyValuesHelper.GetPropertyAsString(cs.cfg, "baseURL", DefaultBaseURL)
text2vec-weaviate goes further and declares an explicit migration away from the lowercase spelling — modules/text2vec-weaviate/module.go:
{Name: "baseUrl", NewName: "baseURL"},
Empirical confirmation
Weaviate 1.39.0, reranker-nvidia enabled, base URL pointed at a stub reranker on the host. Two collections identical but for the key spelling:
baseURL -> stub receives POST /v1/retrieval/nvidia/reranking
query returns the stub's scores: [{"score":2},{"score":1}]
baseUrl -> stub receives nothing
"explorer: get class: extend: extend rerank: client rank:
connection to NVIDIA API failed with status: 401"
The 401 is the module falling back to the real NVIDIA endpoint — the configured URL never reached it.
What misled the original report
Two modules inject their default config under the key nobody reads:
// modules/text2vec-cohere/config.go, modules/text2vec-nvidia/config.go
"baseUrl": ent.DefaultBaseURL,
So for those two modules a baseURL sent by the client appears in the echoed schema next to a baseUrl default, which reads as "unrecognized passthrough key alongside the module's real default". It is the opposite: the client's key is the one the module reads, and the server's default is the one it ignores. Harmless in practice (the reader's fallback default is the same value), but worth reporting upstream as a server-side inconsistency.
Fix
@SerializedName(value = "baseURL", alternate = {"baseUrl"}) on NvidiaReranker.baseUrl, so new configs are written with the key the module reads and configs written by older clients still deserialize.
Version
- java-client 6.3.1
- Weaviate 1.39.0
Summary
rerankers/NvidiaReranker.javasends the base URL asbaseUrl. Thereranker-nvidiamodule readsbaseURL. The value is stored in the schema and then ignored, so reranking silently goes to the default NVIDIA endpoint rather than the configured one.Every other module config in the client (28 classes across vectorizers, generative and
CohereReranker) already usesbaseURLand is correct.Why
baseURLis canonicalModules read the key through
BaseClassSettings.GetPropertyAsString, which bottoms out in a plain case-sensitive map lookup —usecases/modulecomponents/settings/class_settings_property_helper.go:and every module passes
"baseURL":text2vec-weaviategoes further and declares an explicit migration away from the lowercase spelling —modules/text2vec-weaviate/module.go:{Name: "baseUrl", NewName: "baseURL"},Empirical confirmation
Weaviate 1.39.0,
reranker-nvidiaenabled, base URL pointed at a stub reranker on the host. Two collections identical but for the key spelling:The 401 is the module falling back to the real NVIDIA endpoint — the configured URL never reached it.
What misled the original report
Two modules inject their default config under the key nobody reads:
So for those two modules a
baseURLsent by the client appears in the echoed schema next to abaseUrldefault, which reads as "unrecognized passthrough key alongside the module's real default". It is the opposite: the client's key is the one the module reads, and the server's default is the one it ignores. Harmless in practice (the reader's fallback default is the same value), but worth reporting upstream as a server-side inconsistency.Fix
@SerializedName(value = "baseURL", alternate = {"baseUrl"})onNvidiaReranker.baseUrl, so new configs are written with the key the module reads and configs written by older clients still deserialize.Version