#12982·weaviate

reranker-jinaai and reranker-voyageai don't support a configurable baseURL, unlike sibling reranker modules

Author: avanish-gargCreated Sep 7, 2026Updated Sep 7, 2026
Labelsfeature requestcommunity

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