Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#7,409 1 comentario 0 reacciones 2 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

@DeanChensj ya está trabajando en esto.

Desde el 6/10/2026.

  • #7410 de @spandankeche — abierto
  • #7418 de @jennymeshaiah09 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, python
Área
ci-cd

Línea de trabajo

Lee el trabajo Mypy Check en .github/workflows/continuous-integration.yml y compara cómo ejecuta mypy en las ramas base y PR. Reproduce el problema con los pasos del issue, incluido el cambio que solo modifica un comentario en src/google/adk/telemetry/tracing.py; decide si se debe borrar .mypy_cache antes de la comprobación de PR o corregir el error de tipos notificado en src/google/adk/utils/streaming_utils.py. La tarea estará completa cuando la comparación ya no informe de un error sin cambios como si fuera nuevo.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
21.8k
Forks
4.1k
Merge medio
1 d 15 h
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/adk-python

Todos los issues de google/adk-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.