-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow clients to tag requests with a source_tag #324
Conversation
Something else to keep in mind is we would like to track usage of SDKs coming from our own higher-level tools in addition to external integration partners. For example,
This doesn't change a ton about the general strategy, but it makes me think having |
We should also reevaluate some of the cruft that's currently being passed in the user-agent strings. I've been here for a year and never had a need to know anything about what urllib3 version was in use. |
That's good to know that there isn't much relying on what's there currently. Would be nice to identify the high value information we'd like to capture and include. I can understand how it could be helpful to know what http client/version is being used to access the service, particularly if there is a known bug with a particular version that causes trouble for our service, as this would likely help CS triage and help. |
Agree we should capture those clients, but I do wonder if we should try to keep the partner info separate. A lot of that depends on what we end up doing in the back-end, like how this info is extracted and matched up to what's in our partner CRM, etc. In addition to setting the |
FYI there is a minimal unit test file called |
I was working on that concurrently with your comment -- just pushed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach and tests look good to me.
It can be tackled in a different PR if you want, but I think you'll need to go delving into GRPC base.py
code and look at how additional_metadata
gets passed. Unfortunately, I think those data calls are not sending the same user agent currently as gets sent with REST calls.
85a59af
to
4d19d19
Compare
* 'main' of github.com:pinecone-io/pinecone-python-client: [skip ci] Bump version to v4.1.0 Bump tqdm from 4.66.1 to 4.66.3 (pinecone-io#344) Bump idna from 3.4 to 3.7 (pinecone-io#345) Bump jinja2 from 3.1.3 to 3.1.4 (pinecone-io#343) Add better error messages for mistaken `from_texts` and `from_documents` (pinecone-io#342) Support proxy_url and ssl_ca_certs options for gRPC (pinecone-io#341) Remove serverless public preview warnings (pinecone-io#340) [skip ci] Bump version to v4.0.0 Improve upsert throughput by 3x (pinecone-io#334) Remove `merge` workflow and update `build-and-publish-docs` workflow to be manually runnable (pinecone-io#335) [skip ci] Bump version to v3.2.2 [Fix] openapi_config deprecation warning incorrectly shown (pinecone-io#327) Add grpc unit test run, expand testing of VectorFactory (pinecone-io#326) [skip ci] Bump version to v3.2.1 Allow clients to tag requests with a source_tag (pinecone-io#324) [skip ci] Bump version to v3.2.0 Revise proxy configuration, add integration testing (pinecone-io#325) [Fix] Configuring SSL proxy via openapi_config object (pinecone-io#321) Update README.md (pinecone-io#323)
Problem
Need to allow clients to include a
source_tag
to identify the source of their requests.Solution
Allow clients to specify a
source_tag
field in the client constructor, that will be used to identify the traffic source, if applicable.Example:
This would cause the user-agent to get a value like:
Type of Change
Testing