Repository navigation
Fix Vertex AI hook silently discarding credentials when vertexai flag is set - #72012
Conversation
ColtenOuO
left a comment
There was a problem hiding this comment.
Thanks! Just noticed a minor thing here:
In pydantic_ai.py:466 -- The class docstring's example JSON (Connection fields section) still includes "vertexai": true here, but the prose right below it (lines 472-473 in this PR's diff) now says the field has no effect.
Since the get_ui_field_behaviour() placeholder a few lines down (line 492) was already updated to drop vertexai, could this example be updated the same way so the two don't contradict each other?
… is set Setting "vertexai": true/false in the PydanticAIVertexHook connection extra made the provider constructor call raise TypeError, since neither GoogleProvider nor GoogleCloudProvider in the currently pinned pydantic-ai accept a vertexai constructor kwarg anymore (that distinction moved to a dedicated provider class upstream). The base hook's TypeError fallback then silently re-resolved credentials from environment variables only, discarding project/location/ service_account_info/api_key with just a WARNING log line as a hint. The field is now accepted but never forwarded to the provider constructor, so the rest of the explicit credentials still apply.
30c12ac to
afc0194
Compare
Good catch! Just updated it |
…test The Vertex hook's tests still built their connection extras from "google-vertex:gemini-2.0-flash", a provider id pydantic-ai no longer recognizes -- it was renamed to "google-cloud:" when GoogleProvider(vertexai=True) was split into GoogleProvider and GoogleCloudProvider (pydantic/pydantic-ai#5336). The user-facing strings were corrected in apache#72012, but the fixtures kept exercising a prefix that raises "Unknown provider" in real use, so nothing in the suite would notice the documented example drifting away from a working one again. Align the fixtures with the prefix the hook now documents and add a test that resolves it through pydantic-ai's own provider lookup rather than a mock.
…test The Vertex hook's tests still built their connection extras from "google-vertex:gemini-2.0-flash", a provider id pydantic-ai no longer recognizes -- it was renamed to "google-cloud:" when GoogleProvider(vertexai=True) was split into GoogleProvider and GoogleCloudProvider (pydantic/pydantic-ai#5336). The user-facing strings were corrected in apache#72012, but the fixtures kept exercising a prefix that raises "Unknown provider" in real use, so nothing in the suite would notice the documented example drifting away from a working one again. Align the fixtures with the prefix the hook now documents and add a test that resolves it through pydantic-ai's own provider lookup rather than a mock.
…test The Vertex hook's tests still built their connection extras from "google-vertex:gemini-2.0-flash", a provider id pydantic-ai no longer recognizes -- it was renamed to "google-cloud:" when GoogleProvider(vertexai=True) was split into GoogleProvider and GoogleCloudProvider (pydantic/pydantic-ai#5336). The user-facing strings were corrected in apache#72012, but the fixtures kept exercising a prefix that raises "Unknown provider" in real use, so nothing in the suite would notice the documented example drifting away from a working one again. Align the fixtures with the prefix the hook now documents and add a test that resolves it through pydantic-ai's own provider lookup rather than a mock.
Setting "vertexai": true/false in the PydanticAIVertexHook connection extra made the provider constructor call raise TypeError, since neither GoogleProvider nor GoogleCloudProvider in the currently pinned pydantic-ai accept a vertexai constructor kwarg anymore (that distinction moved to a dedicated provider class upstream). The base hook's TypeError fallback then silently re-resolved credentials from environment variables only, discarding project/location/ service_account_info/api_key with just a WARNING log line as a hint.
The field is now accepted but never forwarded to the provider constructor, so the rest of the explicit credentials still apply.
Was generative AI tooling used to co-author this PR?
Generated-by: [Tool Name] following the guidelines
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.