[dudanogueira]

Weaviate 1.38+ reads the X-Weaviate-Client-Integration request header, formatted {name}/{version}, to attribute traffic to the integration that sent it. Other integrations already send it: crewAI sends crewai-tools/<version>, Dify dify/<version>, Haystack haystack-python/<version>. Older Weaviate versions ignore the header.

What changed

• llmstack/processors/providers/weaviate: new with_integration_header() helper. It adds llmstack/<version>, using the installed package version and unknown when that isn't available.
• _create_weaviate_client (the datasource vector store) and the legacy common/blocks Weaviate store pass their headers through the helper. Because the header is part of the client's headers at construction, it is sent on every REST request and in the gRPC metadata.
• A header with the same name supplied by the user in the provider's additional headers is left untouched.
• Telemetry can't break the client: version lookup failures fall back to unknown.

How tested

Against Weaviate 1.39.13 with weaviate-client 4.7.1, captured outgoing traffic:

• every REST request, including the initial /v1/meta, and the gRPC metadata carry X-Weaviate-Client-Integration: llmstack/<version>
• a user-supplied value wins on both REST and gRPC
• the legacy v3 client sends it too
• the existing datasource flow (create collection, batch add, hybrid query, delete) is unchanged

Note: the Docker image installs dependencies with --no-root, so containers report llmstack/unknown until the package itself is installed in the image.

[vercel]

@dudanogueira is attempting to deploy a commit to the LLMStack Team on Vercel.

A member of the Team first needs to authorize it.