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

閱讀 .github/workflows/continuous-integration.yml 中的 Mypy Check 工作，並比較它在 base 和 PR 分支上執行 mypy 的方式。按照 issue 中的步驟重現問題，包括只修改 src/google/adk/telemetry/tracing.py 中註解的變更；判斷應在 PR 檢查前清除 .mypy_cache，還是處理 src/google/adk/utils/streaming_utils.py 中回報的型別錯誤。完成標準是比較結果不再將未變更的錯誤回報為新錯誤。

🔴 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.