Skip to content

feat(generative): add location to GenerativeConfig.google_vertex runtime config (#2073) - #2130

Open
Anai-Guo wants to merge 1 commit into
weaviate:mainfrom
Anai-Guo:feat/generative-runtime-google-location
Open

feat(generative): add location to GenerativeConfig.google_vertex runtime config (#2073)#2130
Anai-Guo wants to merge 1 commit into
weaviate:mainfrom
Anai-Guo:feat/generative-runtime-google-location

Conversation

@Anai-Guo

Copy link
Copy Markdown
Contributor

What

Follow-up to #2118 (which added location to the collection-level Configure.Generative.google_vertex). This wires the same location through the per-query runtime config, GenerativeConfig.google_vertex.

Weaviate core's generative-google module reads a location class setting (default us-central1) alongside region, and now that the GenerativeGoogle proto carries location (field 15, from your regen in f58e35b6), the runtime path can send it:

  • add location to _GenerativeGoogle
  • pass location=self.location in _to_grpc
  • expose an optional location= argument on GenerativeConfig.google_vertex, appended at the end of the signature so positional callers are unaffected

When left as None it is omitted from the gRPC message, so the server default still applies and existing calls are unchanged.

Test

Added a google_vertex case to test_generative_parameters asserting location="us-central1" round-trips into generative_pb2.GenerativeGoogle(location=...). All 21 cases pass; on unmodified code the new case fails with TypeError: google_vertex() got an unexpected keyword argument 'location', confirming the field actually flows.

Note on the proto files

The six generative_pb2 files in this diff are identical to main (your f58e35b6 regen). They're included only so CI is green on this branch — my fork can't fast-forward past the CI-workflow commit without the workflow token scope, so I couldn't rebase onto the new protos. They 3-way-merge to a no-op against main; feel free to drop them on merge/rebase.

🤖 Generated with Claude Code

…ime config (weaviate#2073)

The generative-google module in Weaviate core reads a location setting
(default us-central1) alongside region, and the collection-level config
(Configure.Generative.google_vertex) already exposes it. The per-query
runtime path (GenerativeConfig.google_vertex) had no way to send it.

Now that GenerativeGoogle carries the location field (field 15) in the
regenerated protos, wire it through: add location to _GenerativeGoogle,
pass it in _to_grpc, and expose an optional location argument on
GenerativeConfig.google_vertex. It is appended at the end of the
signature so positional callers are unaffected, and omitted from the
gRPC message when left as None, so the server default still applies.

The six generative_pb2 files mirror main's proto regen (f58e35b); they
are included only so CI is green on this branch and no-op on merge.

Signed-off-by: Tai An <antai12232931@anaiguo.com>
@Anai-Guo

Copy link
Copy Markdown
Contributor Author

I agree with the Weaviate Contributor License Agreement.

@orca-security-eu orca-security-eu Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Orca Security Scan Summary

Status Check Issues by priority
Passed Passed Infrastructure as Code high 0   medium 0   low 0   info 0 View in Orca
Passed Passed SAST high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Secrets high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Vulnerabilities high 0   medium 0   low 0   info 0 View in Orca

@weaviate-git-bot

Copy link
Copy Markdown

To avoid any confusion in the future about your contribution to Weaviate, we work with a Contributor License Agreement. If you agree, you can simply add a comment to this PR that you agree with the CLA so that we can merge.

beep boop - the Weaviate bot 👋🤖

PS:
Are you already a member of the Weaviate Forum?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants