Related issues:
Crash Report
Since SQLite has become the default cache mypy crashes on different platforms and Python versions in various Action runs: v2.1.0 run, v2.2.0 run, and v2.3.0 run. This appears to happen only if the .mypy_cache/ folder is missing; if it exists then mypy runs ok. (I didn’t poke around that folder, though.) See below.
Traceback
error: INTERNAL ERROR -- Please try using mypy master on GitHub:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 2.3.0
Traceback (most recent call last):
File "/path/to/python-package-template/.venv/lib/python3.14/site-packages/mypy/__main__.py", line 16, in console_entry
main()
~~~~^^
File "mypy/main.py", line 154, in main
File "mypy/main.py", line 244, in run_build
res = build.build(sources, options, None, flush_errors, fscache, stdout, stderr)
File "mypy/build.py", line 385, in build
File "mypy/build.py", line 1908, in create_metastore
mds: MetadataStore = SqliteMetadataStore(
File "mypy/metastore.py", line 200, in __init__
File "mypy/metastore.py", line 174, in connect_db
db.execute("PRAGMA journal_mode=WAL")
sqlite3.OperationalError: database is locked
More variations of this error are linked through the above runs.
To Reproduce
I didn’t do nothin’ 🤓
As per PR jenstroeger/python-package-template#1238 this started happening when moving to mypy v2.0.0 which uses the SQLite cache. At first I thought it’s got to do with the new parallel type-checking but whether that’s en/disabled doesn’t actually matter. Whether a .mypy_cache/ already exists does: remove the folder to make mypy crash, or leave the folder in place (even after a crash) and mypy works ok.
Your Environment
I can reproduce this issue reliably locally on macOS Ventura 13.7.8 with Python 3.14.6, and as per linked CI runs above this happens across platforms and Python versions.
- Mypy version used: v2.1.0 and v2.2.0 and v2.3.0
- Mypy command-line flags:
--explicit-package-bases --show-traceback --config-file pyproject.toml
- Mypy configuration options from
pyproject.toml (via pre-commit):
[tool.mypy]
# mypy_path =
# exclude =
# num_workers =
show_error_codes = true
show_column_numbers = true
pretty = true
show_traceback = true
check_untyped_defs = true
incremental = false
strict = true
warn_return_any = true
warn_redundant_casts = true
warn_unreachable = true
warn_unused_configs = true
warn_unused_ignores = true
disallow_any_explicit = true
disallow_untyped_calls = true
disallow_untyped_defs = true
disallow_incomplete_defs = true
disallow_untyped_decorators = true
# disable_error_code =
# allow_redefinition =
no_sqlite_cache = true
[[tool.mypy.overrides]]
module = [
"pytest.*",
]
ignore_missing_imports = true
- Python version used: from 3.10 through 3.14
- Operating system and version: Linux, Windows, macOS
Related issues:
Crash Report
Since SQLite has become the default cache
mypycrashes on different platforms and Python versions in various Action runs: v2.1.0 run, v2.2.0 run, and v2.3.0 run. This appears to happen only if the.mypy_cache/folder is missing; if it exists thenmypyruns ok. (I didn’t poke around that folder, though.) See below.Traceback
More variations of this error are linked through the above runs.
To Reproduce
I didn’t do nothin’ 🤓
As per PR jenstroeger/python-package-template#1238 this started happening when moving to
mypyv2.0.0 which uses the SQLite cache. At first I thought it’s got to do with the new parallel type-checking but whether that’s en/disabled doesn’t actually matter. Whether a.mypy_cache/already exists does: remove the folder to makemypycrash, or leave the folder in place (even after a crash) andmypyworks ok.Your Environment
I can reproduce this issue reliably locally on macOS Ventura 13.7.8 with Python 3.14.6, and as per linked CI runs above this happens across platforms and Python versions.
--explicit-package-bases --show-traceback --config-file pyproject.tomlpyproject.toml(via pre-commit):