Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#7,409 1 bình luận 0 reaction 2 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 6 ngày

@DeanChensj đang làm issue này rồi.

Từ ngày 6/10/2026.

  • #7410 của @spandankeche — đang mở
  • #7418 của @jennymeshaiah09 — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, python
Lĩnh vực
ci-cd

Hướng nghiên cứu

Đọc job Mypy Check trong .github/workflows/continuous-integration.yml và so sánh cách job chạy mypy trên các nhánh base và PR. Tái hiện vấn đề bằng các bước trong issue, bao gồm thay đổi chỉ sửa một chú thích trong src/google/adk/telemetry/tracing.py; quyết định có nên xóa .mypy_cache trước khi kiểm tra PR hay xử lý lỗi kiểu dữ liệu được báo cáo trong src/google/adk/utils/streaming_utils.py. Hoàn tất khi phép so sánh không còn báo cáo một lỗi không thay đổi là lỗi mới.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Python
Star
21.6k
Fork
4k
Merge trung bình
1 ngày 13 giờ
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của google/adk-python

Tất cả issue của google/adk-python

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.