When working with specific environments and hosts that require a non-secure connection, calling pc.Index(pinecone.NewIndexConnParams{Host: idx.Host}) with a Host value that is insecure, you'll run into unexpected behavior seeing :443 attached as a port, or gRPC errors around connecting insecurely without explicitly passing a grpc.DialOption.
Our normalizeHost function has a bug in that it applies port :443 to Host values which are passed without an explicit scheme.
Solution
We can simplify the normalizeHost function to only deal with stripping away any provided scheme, and then checking to see if the connection is explicitly insecure. This is accomplished by providing http:// as a part of the NewIndexConnParams{ Host: yourHost } value, which would need to be accounted for in documentation, etc.
This felt most straightforward because of how the grpc module handles host addresses. Ultimately, we need to strip the scheme off any hosts that are passed, but we also need to decide whether we're dialing in a secure or insecure fashion. I thought of providing an explicit bool as a part of the NewIndexConnParams, but it felt more unwieldy adding new fields.
Type of Change
[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] Infrastructure change (CI configs, etc)
[ ] Non-code change (docs, etc)
[ ] None of the above: (explain here)
Test Plan
I have a local test harness that I'm using to interact with a locally hosted index. I was overriding the go-pinecone package in go.mod to work against my local copy of the SDK. You can pull this branch down and do something similar locally. Here are some of my results:
Problem
When working with specific environments and hosts that require a non-secure connection, calling
pc.Index(pinecone.NewIndexConnParams{Host: idx.Host})with aHostvalue that is insecure, you'll run into unexpected behavior seeing:443attached as a port, or gRPC errors around connecting insecurely without explicitly passing agrpc.DialOption.Our
normalizeHostfunction has a bug in that it applies port:443toHostvalues which are passed without an explicit scheme.Solution
normalizeHostfunction to only deal with stripping away any provided scheme, and then checking to see if the connection is explicitly insecure. This is accomplished by providinghttp://as a part of theNewIndexConnParams{ Host: yourHost }value, which would need to be accounted for in documentation, etc.This felt most straightforward because of how the
grpcmodule handles host addresses. Ultimately, we need to strip the scheme off any hosts that are passed, but we also need to decide whether we're dialing in a secure or insecure fashion. I thought of providing an explicitboolas a part of theNewIndexConnParams, but it felt more unwieldy adding new fields.Type of Change
Test Plan
I have a local test harness that I'm using to interact with a locally hosted index. I was overriding the
go-pineconepackage ingo.modto work against my local copy of the SDK. You can pull this branch down and do something similar locally. Here are some of my results:Before
After