/fixing-ci-annotations

name: fixing-ci-annotations
description: Investigates the check-run annotations (deprecation warnings, resource warnings, logged errors, tool notices) from the latest successful py-unit-tests (max) and js-unit-tests jobs on develop, separates real problems from informational notices, and fixes the causes of the real ones. Use when asked to clean up CI warnings or annotations from passing unit-test jobs, or when the ai-fix-ci-annotations workflow runs.

Fixing CI annotations

Passing unit-test jobs still leave annotations on their check runs: deprecation warnings, `ResourceWarning`s, warnings that pandas, pyarrow, or other libraries raise, errors logged by background threads, and tool notices such as Knip. They don't fail the job, so they pile up and hide new problems. On the Python side, `pytest-github-actions-annotate-failures` turns each entry of the pytest warnings summary into an annotation. GitHub keeps at most 10 warning annotations per step, so the warnings summary in the job log is the complete list.

The goal is a cleaner next run, by fixing what causes each annotation instead of hiding it. Not every annotation is worth a change: some are informational. Decide per annotation whether it points to a real problem before touching code.

Inputs

Job URLs or IDs. Without them, use the latest successful `push` run on `develop` of these jobs:

| Workflow | Job | Why this job | |----------|-----|--------------| | `python-tests.yml` | `py-unit-tests (max)` | Newest supported Python, so deprecations from new Python versions and the dependencies tied to them show up here first | | `js-tests.yml` | `js-unit-tests` | Knip configuration hints. Vitest console output, such as React `act()` warnings, shows up only in the job log, not as annotations |

GitHub's REST run filters (`--branch`, `--status`) can return stale results. Check the run's branch, event, and conclusion yourself.

Workflow

- [ ] Collect and group the annotations
- [ ] Find the test or code that triggers each group
- [ ] Classify: fix, leave, or report
- [ ] Fix and verify
- [ ] Write the summary

1. Collect and group

• List the annotations with `gh api repos/streamlit/streamlit/check-runs/<job-id>/annotations --paginate`. GitHub caps the annotations per step, so use the warnings summary in the job log for the complete set and counts.
• Group the duplicates. The same warning often repeats with different object IDs, memory addresses, or temp paths in its message.
• Annotations on paths under `.github` come from the runner or the workflow, such as runner image migrations or deprecated actions, not from the tests. List them in the summary and leave them alone.
• The annotation points to where the warning was raised. That is often library code or a file under `.venv/`, not the test that caused it. The job log (`gh run view --job <job-id> --log`) shows the pytest warnings summary with test IDs and, for Vitest, the test file around the console output.

2. Find the trigger

• Reproduce locally. For Python, turn the warning into an error and run the suite: `uv run pytest lib/tests -W "error:<start of message>:<Category>"`. Run it serially like CI: some warnings come from process-wide state, and `-n auto` can hide them or the test that triggers them. The failing tests are the triggers. Warnings logged through `logging` don't respond to `-W`; search the log for the test that ran when they appeared.
• For JavaScript, run the affected test files with Vitest and check the console output, or `make frontend-knip` for Knip notices.
• Some warnings only show up on Linux, on the newest Python, or with the newest dependency versions. The CI runner is Linux. If a warning doesn't reproduce, reason from the message, the code, and the dependency version in `uv.lock`.

3. Classify

| Decision | Signals | |----------|---------| | **fix** | Streamlit code calls a deprecated API that has a replacement. A test leaks resources (unclosed files, sockets, event loops, threads, observers), leaves a coroutine unawaited, watches a shared directory such as `/tmp`, or misses a mock. A test triggers the warning on purpose to cover an edge case, and a one-line scoped assertion or filter keeps it out of the run. Library code shows users a warning it shouldn't. React `act()` warnings and other console errors in the Vitest log. Knip configuration hints, such as stale `ignore` entries. | | **leave** (informational) | The annotation describes expected behavior and points to no problem: progress or summary notices from a tool, a library's one-time info message, or a warning whose only fix would make the test or the code worse. Leave these alone and say why in the summary. | | **report** | The warning comes from third-party internals that Streamlit can't avoid. If a compatible upgrade would fix it, name the package and version so the weekly lock update or a maintainer picks it up. The fix needs a `.github/workflows/` change, a major dependency upgrade, or a product decision. A commit on `develop` since the run, or an open PR, already handles it. This includes PRs on `ai-fix-ci-annotations-*` branches from earlier runs. For unavoidable third-party warnings, suggest a module-scoped `filterwarnings` entry like those in `lib/pyproject.toml`. |

4. Fix and verify

• Fix the root cause with the smallest change. When migrating off a deprecated API, keep working with the minimum dependency versions in `lib/pyproject.toml`.
• When a test triggers a warning on purpose, assert it with `pytest.warns`, or scope `@pytest.mark.filterwarnings` to that test or parameter. In Vitest, spy on the console and assert the call.
• Don't add global warning filters (`filterwarnings` in `pyproject.toml`, Vitest config), silence loggers, skip or delete tests, or loosen assertions to get a clean run.
• Verify each fix: rerun the triggering tests with the warning turned into an error, then run `make check`.
• Keep the change easy to review in one sitting. If ther