Is this a new bug?
Current Behavior
On v9 there is no clean, documented way to target a Pinecone Local index over plain HTTP.
The data-plane host resolved from pc.indexes.describe(...).host ends up as an https target, and v9 exposes no TLS-off switch (the old GRPCClientConfig(secure=False) and the pinecone.grpc import path were removed in the rewrite).
Pinecone Local serves http only, so the connection fails.
To get it working I have to hand-edit the scheme on the host string before passing it to pc.index(...):
index_info = pc.indexes.describe(...)
data_host = index_info.host #Regardless of whether the original host was http://localhost:5080 or localhost:5080, the host received here is https://localhost:5081
I debugged it to find out that the response received from 'http://localhost:5080/indexes/<index_name>' does not contain any URL scheme. As a result, when IndexModel class is initiated based on the response, the normalize_host function auto forces https on it.
This behaviour has not been documented in the local development docs of python. Although it is covered in the docs of other languages.
Workaround:
data_host = data_host.replace("https://", "http://")
index = pc.index(host=data_host)
Separately, the official local-dev guide
(https://docs.pinecone.io/guides/operations/local-development) still shows the pre-v9 example from pinecone.grpc import PineconeGRPC, GRPCClientConfig, which raises ImportError: cannot import name 'GRPCClientConfig' from 'pinecone.grpc' on v9.
This I believe could be the reason of the whole thing. In the example GRPCClientConfig(secure=False) must be making sure that SSL is not used. And without it ssl_verify=False set inside pc is not reaching pc.index
pc = Pinecone(api_key="[ENCRYPTION_KEY]", host=_local_host, ssl_verify=False)
Expected Behavior
A supported way to talk to easily talk to local pinecone server, ideally one of:
- a TLS-off option on
pc.index(...) (a v9 equivalent of secure=False), or
- the client auto-using http when the host is localhost / 127.0.0.1, or
- ssl_verify=False auto reaching
pc.index thus forcing normalize_host to enforce http instead of https
- at minimum, documentation of this issue on https://docs.pinecone.io/guides/operations/local-development (Python version) so others trying out the example as is do not have to waste their time debugging this.
I should not have to mutate the internal host value to pick a scheme. Even if I have to someone should let me know.
The port of getting the index is different too, it hits 5081 instead of 5080 so there should be someway to raise this warning as well so that the users facing this issue, upon manually copying the localhost address in both places could get a hint what might be going wrong.
Steps To Reproduce
- Start Pinecone Local (database emulator) on http://localhost:5080 via Docker.
uv add pinecone (pinecone==9.0.1).
- Run:
from pinecone import Pinecone, ServerlessSpec
LOCAL_HOST = "http://localhost:5080"
INDEX_NAME = "testing"
# 1. client pointed at Pinecone Local
pc = Pinecone(api_key="abcd", host=LOCAL_HOST)
# 2. create the index if missing
if not pc.has_index(INDEX_NAME):
pc.indexes.create(name=INDEX_NAME,spec=ServerlessSpec(cloud='aws', region="us-east-1"),)
# 3. get the host
info = pc.indexes.describe(name=INDEX_NAME)
# 4. Error at -
index = pc.index(name=index_name,host=info.host)
- Connection fails. Replacing/prefixing the scheme to http on
info.host is the only way I found to make it work.
# After 3
data_host = info.host.replace("https://", "http://")
index = pc.index(name=index_name, host=data_host)
Relevant log output
Traceback (most recent call last):
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpx\_transports\default.py", line 101, in map_httpcore_exceptions
yield
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpx\_transports\default.py", line 250, in handle_request
resp = self._pool.handle_request(req)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpcore\_sync\connection_pool.py", line 256, in handle_request
raise exc from None
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpcore\_sync\connection_pool.py", line 236, in handle_request
response = connection.handle_request(
pool_request.request
)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpcore\_sync\connection.py", line 101, in handle_request
raise exc
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpcore\_sync\connection.py", line 78, in handle_request
stream = self._connect(request)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpcore\_sync\connection.py", line 156, in _connect
stream = stream.start_tls(**kwargs)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpcore\_backends\sync.py", line 154, in start_tls
with map_exceptions(exc_map):
~~~~~~~~~~~~~~^^^^^^^^^
File "C:\Users\deeks\AppData\Roaming\uv\python\cpython-3.13-windows-x86_64-none\Lib\contextlib.py", line 162, in __exit__
self.gen.throw(value)
~~~~~~~~~~~~~~^^^^^^^
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpcore\_exceptions.py", line 14, in map_exceptions
raise to_exc(exc) from exc
httpcore.ConnectError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1032)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\pinecone\_internal\http_client.py", line 511, in post
response = self._client._transport.handle_request(request)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\pinecone\_internal\http_client.py", line 165, in handle_request
raise last_exc
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\pinecone\_internal\http_client.py", line 136, in handle_request
response = self._transport.handle_request(request)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpx\_transports\default.py", line 249, in handle_request
with map_httpcore_exceptions():
~~~~~~~~~~~~~~~~~~~~~~~^^
File "C:\Users\deeks\AppData\Roaming\uv\python\cpython-3.13-windows-x86_64-none\Lib\contextlib.py", line 162, in __exit__
self.gen.throw(value)
~~~~~~~~~~~~~~^^^^^^^
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\httpx\_transports\default.py", line 118, in map_httpcore_exceptions
raise mapped_exc(message) from exc
httpx.ConnectError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1032)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "E:\Projects\SSNanopore_rag\.venv\Scripts\check.exe\__main__.py", line 10, in <module>
sys.exit(main())
~~~~^^
File "E:\Projects\SSNanopore_rag\src\ssnanopore_rag\embeddingStore.py", line 148, in main
store.add_embeddings(
~~~~~~~~~~~~~~~~~~~~^
ids=["good", "bad"],
^^^^^^^^^^^^^^^^^^^^
documents=["what is DNA sequencing?", "what is CRISPR?"],
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
metadata=[{"title": "DNA Sequencing"}, {"title": "CRISPR"}],
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "E:\Projects\SSNanopore_rag\src\ssnanopore_rag\embeddingStore.py", line 96, in add_embeddings
self.index.upsert(
~~~~~~~~~~~~~~~~~^
vectors=[
^^^^^^^^^
...<7 lines>...
namespace=namespace
^^^^^^^^^^^^^^^^^^^
)
^
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\pinecone\_legacy\async_req.py", line 95, in wrapper
return canonical(*args, **kwargs)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\pinecone\index\__init__.py", line 275, in upsert
return self._upsert_one_batch(vectors=vectors, namespace=namespace, timeout=timeout)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\pinecone\index\__init__.py", line 335, in _upsert_one_batch
response = self._http.post("/vectors/upsert", timeout=timeout, json=body)
File "E:\Projects\SSNanopore_rag\.venv\Lib\site-packages\pinecone\_internal\http_client.py", line 521, in post
raise PineconeConnectionError(str(exc)) from exc
pinecone.errors.exceptions.PineconeConnectionError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1032)
Environment
- **OS**: Windows 11 (uv)
- **Language version**: Python 3.13.13
- **Pinecone client version**: 9.0.1
Additional Context
https://docs.pinecone.io/guides/operations/local-development#2-develop-your-app
Is this a new bug?
Current Behavior
On v9 there is no clean, documented way to target a Pinecone Local index over plain HTTP.
The data-plane host resolved from
pc.indexes.describe(...).hostends up as an https target, and v9 exposes no TLS-off switch (the oldGRPCClientConfig(secure=False)and thepinecone.grpcimport path were removed in the rewrite).Pinecone Local serves http only, so the connection fails.
To get it working I have to hand-edit the scheme on the host string before passing it to
pc.index(...):I debugged it to find out that the response received from 'http://localhost:5080/indexes/<index_name>' does not contain any URL scheme. As a result, when
IndexModelclass is initiated based on the response, the normalize_host function auto forceshttpson it.This behaviour has not been documented in the local development docs of python. Although it is covered in the docs of other languages.
Workaround:
Separately, the official local-dev guide
(https://docs.pinecone.io/guides/operations/local-development) still shows the pre-v9 example
from pinecone.grpc import PineconeGRPC, GRPCClientConfig, which raisesImportError: cannot import name 'GRPCClientConfig' from 'pinecone.grpc'on v9.This I believe could be the reason of the whole thing. In the example
GRPCClientConfig(secure=False)must be making sure that SSL is not used. And without itssl_verify=Falseset inside pc is not reachingpc.indexExpected Behavior
A supported way to talk to easily talk to local pinecone server, ideally one of:
pc.index(...)(a v9 equivalent ofsecure=False), orpc.indexthus forcingnormalize_hostto enforcehttpinstead ofhttpsI should not have to mutate the internal host value to pick a scheme. Even if I have to someone should let me know.
The port of getting the index is different too, it hits
5081instead of5080so there should be someway to raise this warning as well so that the users facing this issue, upon manually copying the localhost address in both places could get a hint what might be going wrong.Steps To Reproduce
uv add pinecone(pinecone==9.0.1).info.hostis the only way I found to make it work.Relevant log output
Environment
Additional Context
https://docs.pinecone.io/guides/operations/local-development#2-develop-your-app