reranker-jinaai and reranker-voyageai don't support a configurable baseURL, unlike sibling reranker modules
Describe your feature request
reranker-cohere and reranker-nvidia both expose a baseURL class-setting (with
SSRF-hardening validation) plus a per-request X-Cohere-Baseurl/X-Nvidia-Baseurl header
override — see modules/reranker-cohere/config/class_settings.go and
modules/reranker-nvidia/config/class_settings.go.
reranker-jinaai and reranker-voyageai have no equivalent. Both hardcode their API host
directly in the client struct (modules/reranker-jinaai/clients/ranker.go:53,
modules/reranker-voyageai/clients/ranker.go:53), and neither module's class_settings.go
defines a BaseURL() method at all.
This looks like an oversight rather than a design choice: the identical gap was previously
filed for reranker-cohere (#9538) and fixed in #10878 — which also touched
reranker-jinaai/clients/ranker.go and reranker-voyageai/clients/ranker.go in the same
diff (reformatting an error string, swapping in NewBaseHttpClient) without adding the
baseURL capability to either, while adding it to reranker-nvidia in that same commit.
A later security PR (#11683, closing an SSRF bypass on the header override) touched
reranker-cohere and reranker-nvidia again and again passed over jinaai/voyageai.
Use case: self-hosted/proxied Jina AI or Voyage AI endpoints (or region-specific API gateways) currently have no way to point these two rerankers anywhere but the public default host, unlike every other HTTP-based reranker module.
Happy to open a PR — I have a working implementation mirroring the
reranker-cohere/reranker-nvidia pattern exactly, with unit tests.
Code of Conduct
- I have read and agree to the Weaviate's Contributor Guide and Code of Conduct
Source: weaviate/weaviate