Skip to content

Fix type checking for google-genai 2.12.0#1652

Open
DABH wants to merge 3 commits into
mainfrom
google-genai-2.12-compat
Open

Fix type checking for google-genai 2.12.0#1652
DABH wants to merge 3 commits into
mainfrom
google-genai-2.12-compat

Conversation

@DABH

@DABH DABH commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

What

google-genai 2.12.0 (released 2026-07-16, within our >=2.10.0,<3.0.0 range) broke type checking of temporalio.contrib.google_genai: test-latest-deps fails with 34 mypy errors (isinstance with a TypeAliasType, missing id/status attributes). Every branch's next test-latest-deps run fails the same way.

Why

2.12.0's google.genai.interactions exports two Interaction names: the interaction resource class and a TypeAliasType over the trigger-request variants (CreateAgentInteraction | CreateModelInteraction). The module deliberately orders its star-imports so the resource class wins at runtime (per the comment in that module), but type checkers resolve the name to the alias, which fails (doesn't work with isinstance, no resource fields).

How

A new _compat.py shim:

  • runtime: unchanged; still binds google.genai.interactions.Interaction (verified the imported object is identical under 2.10.0 and 2.12.0, so there is no functionality change);
  • static (TYPE_CHECKING): binds the class' defining module, which is the same location in 2.10.x and 2.12.0.

The three import sites (_gemini_activity, _temporal_interactions, test_gemini) go through the shim. Remove the shim once upstream exports the resource class unambiguously for type checkers.

Verification

All tests and CI checks pass now with 2.10 and 2.12

google-genai 2.12.0 exports two Interaction names from
google.genai.interactions: the interaction resource class and a
TypeAliasType over the trigger-request variants. Runtime star-import
ordering deliberately binds the name to the resource class, but type
checkers resolve it to the alias, which cannot be used with isinstance
and lacks the resource fields — mypy fails with 34 errors (first seen
on test-latest-deps when 2.12.0 released).

Add a _compat shim that keeps the runtime binding on the public path
(the imported object is unchanged — identity-verified against 2.10.0
and 2.12.0) and points the static view at the class's defining module,
which is the same location in both versions. Redirect the three import
sites through the shim.

Verified with mypy, pyright, and basedpyright plus the google_genai
test suite (62 passed) under both google-genai 2.10.0 (locked) and
2.12.0 (latest).
@DABH DABH requested review from a team as code owners July 16, 2026 04:43
@DABH DABH changed the title Fix google_genai type checking under google-genai 2.12.0 Fix type checking for google-genai 2.12.0 Jul 16, 2026
@DABH

DABH commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

Upstream issue filed: googleapis/python-genai#2732 (tracks the export collision; when it's fixed, _compat.py can be removed).

@brianstrauch brianstrauch left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks for finding this breaking change! Once 2.12 is at least two weeks old we can set the dependency range to [2.12, 3) and make this the default, unless we have an upstream fix by then.

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