Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

CI Mypy Check flags an existing streaming_utils.py error as new because the PR run reuses the baseline's mypy cache

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#7,409 1 Kommentar 0 Reaktionen 2 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 6 Tagen

@DeanChensj arbeitet bereits daran.

Seit 06.10.2026.

  • #7410 von @spandankeche — offen
  • #7418 von @jennymeshaiah09 — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, python
Bereich
ci-cd

Rechercherichtung

Lies den Job Mypy Check in .github/workflows/continuous-integration.yml und vergleiche, wie er mypy auf den Base- und PR-Branches ausführt. Reproduziere das Problem mit den Schritten im Issue, einschließlich der Änderung, die nur einen Kommentar in src/google/adk/telemetry/tracing.py betrifft; entscheide, ob .mypy_cache vor der PR-Prüfung geleert oder der gemeldete Typfehler in src/google/adk/utils/streaming_utils.py behoben werden sollte. Fertig ist die Aufgabe, wenn der Vergleich einen unveränderten Fehler nicht mehr als neu meldet.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

needs review

🔴 Required Information

Describe the Bug:
The Mypy Check job in .github/workflows/continuous-integration.yml runs mypy . on the base branch and then on the PR commit in the same checkout, so the PR run reuses the .mypy_cache that the baseline run wrote. For one error that already exists on main, in src/google/adk/utils/streaming_utils.py, mypy prints the members of an inferred Literal[...] type in a different order when it reads them from the cache. The job compares the two error lists as text with comm -13, so the reordered message counts as a new error and the job fails, although nothing changed.

Any pull request that edits a module mypy re-checks together with streaming_utils.py can hit this. A comment-only change to src/google/adk/telemetry/tracing.py is enough. I ran into it while preparing a PR for #7345.

Steps to Reproduce:

  1. Check out main (reproduced at 63aed5511) and install the way the job does: 
    uv venv --python 3.13 .venv && source .venv/bin/activate
uv sync --all-extras --no-install-package lancedb
  2. Produce the baseline the way the job does, starting with no cache: 
    rm -rf .mypy_cache
uv run mypy . | grep "error:" | sed 's/:\([0-9]\+\):/::/g' | sort > baseline_errors.txt
  3. Make a comment-only change and run mypy again, now reusing that cache: 
    echo "# comment-only change" >> src/google/adk/telemetry/tracing.py
uv run mypy . | grep "error:" | sed 's/:\([0-9]\+\):/::/g' | sort > pr_errors.txt
  4. Compare them as the job does: 
    comm -13 baseline_errors.txt pr_errors.txt

Expected Behavior:
No output, because a comment cannot introduce a type error.

Observed Behavior:
One "new" error. Both runs report 805 errors, and the only difference is the order of the Literal members in this message from streaming_utils.py line 581 (error_code = self._response.prompt_feedback.block_reason). The fresh run lists them in declaration order, the cached run alphabetically:

fresh:  ... variable has type "Literal[FinishReason.FINISH_REASON_UNSPECIFIED, FinishReason.MAX_TOKENS, FinishReason.SAFETY, ...] | None")  [assignment]
cached: ... variable has type "Literal[FinishReason.BLOCKLIST, FinishReason.CONTINUATION, FinishReason.FINISH_REASON_UNSPECIFIED, ...] | None")  [assignment]

Environment Details:

  • ADK Library Version: main at 63aed5511 (2.11.0)
  • Desktop OS: Linux (Ubuntu on WSL2), following the job's steps for ubuntu-latest
  • Python Version: 3.10, 3.11, 3.12 and 3.13 (the job's matrix), mypy 2.4.0; same result on all four

Model Information:

  • Are you using LiteLLM: N/A
  • Which model is being used: N/A (CI type check only)

🟡 Optional Information

Regression:
Not a change in ADK behaviour. It appears whenever a PR touches a module in the same re-check set as streaming_utils.py.

Logs:

fresh run:
src/google/adk/utils/streaming_utils.py:: error: Incompatible types in assignment (expression has type "BlockedReason | None", variable has type "Literal[FinishReason.FINISH_REASON_UNSPECIFIED, FinishReason.MAX_TOKENS, FinishReason.SAFETY, FinishReason.RECITATION, FinishReason.LANGUAGE, FinishReason.OTHER, FinishReason.BLOCKLIST, FinishReason.PROHIBITED_CONTENT, FinishReason.SPII, FinishReason.MALFORMED_FUNCTION_CALL, FinishReason.IMAGE_SAFETY, FinishReason.UNEXPECTED_TOOL_CALL, FinishReason.TOO_MANY_TOOL_CALLS, FinishReason.IMAGE_PROHIBITED_CONTENT, FinishReason.NO_IMAGE, FinishReason.IMAGE_RECITATION, FinishReason.IMAGE_OTHER, FinishReason.CONTINUATION] | None")  [assignment]                                                                                                                 
cached run:
src/google/adk/utils/streaming_utils.py:: error: Incompatible types in assignment (expression has type "BlockedReason | None", variable has type "Literal[FinishReason.BLOCKLIST, FinishReason.CONTINUATION, FinishReason.FINISH_REASON_UNSPECIFIED, FinishReason.IMAGE_OTHER, FinishReason.IMAGE_PROHIBITED_CONTENT, FinishReason.IMAGE_RECITATION, FinishReason.IMAGE_SAFETY, FinishReason.LANGUAGE, FinishReason.MALFORMED_FUNCTION_CALL, FinishReason.MAX_TOKENS, FinishReason.NO_IMAGE, FinishReason.OTHER, FinishReason.PROHIBITED_CONTENT, FinishReason.RECITATION, FinishReason.SAFETY, FinishReason.SPII, FinishReason.TOO_MANY_TOOL_CALLS, FinishReason.UNEXPECTED_TOOL_CALL] | None")  [assignment]

Additional Context:
Two possible fixes; I'm happy to open a PR for whichever you prefer:

  1. In the workflow: run rm -rf .mypy_cache in the "Check PR Branch" step before mypy ., so both runs start fresh and print the same order. Checked without a cache, my PR commit reports 805 errors and 0 new ones against the baseline. The cost is that the PR-side run re-checks everything instead of reusing the cache, about 1.5 minutes locally.
  2. In the code: annotate the variable in streaming_utils.py as error_code: Optional[str] = None, the type of LlmResponse.error_code. FinishReason and BlockedReason both subclass str, so both assignments type-check and the error itself goes away. That removes this instance, but not the cache behaviour that could reorder another message later.

How often has this issue occurred?:

  • Always (100%) with the steps above.
Vorherrschende Sprache
Python
Sterne
21.6k
Forks
4k
Ø Merge
1 T. 13 Std.
Gemergte PRs (30 T.)
6

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus google/adk-python

Alle Issues in google/adk-python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.