mypy / pyright Fail CI After a Version or Strictness Change

Type checkers get stricter over time. A new mypy/pyright release, updated bundled type stubs, or a flipped strictness flag can surface errors that the previous version never reported - a tooling change, not a code regression.

What this error means

CI type-checking fails with errors on code that passed before, and no relevant code changed. The mypy/pyright version (or a stubs package) bumped; pinning the prior version clears the new errors.

mypy output

app/db.py:30: error: Returning Any from function declared to return "int"  [no-any-return]
Found 12 errors in 4 files (checked 60 source files)
# mypy 1.10 -> 1.11 enabled a stricter check or pulled newer stubs

Common causes

Type checker upgraded between runs

An unpinned mypy/pyright installs the latest, which adds checks or tightens inference, flagging code the old version accepted.

Updated or newly-installed stubs

A bumped types-* package or bundled stub set gives more precise types, exposing mismatches that loose stubs previously hid.

How to fix it

Pin the checker and stub versions

Pin mypy/pyright and any types-* stubs so type-checking is reproducible.

requirements-dev.txt

# requirements-dev.txt
mypy==1.10.1
types-requests==2.32.0.20240914

Adopt the stricter result deliberately

When upgrading, fix the new errors or scope the strictness, rather than letting an unpinned bump break CI.

pyproject.toml

# pin behavior so upgrades are intentional
[tool.mypy]
python_version = "3.12"
warn_return_any = true

How to prevent it

Pin mypy/pyright and types-* stub versions in CI.
Upgrade type checkers in a dedicated change and fix new findings.
Set python_version/typeCheckingMode explicitly so behavior is stable.