Internal error: KeyError 'setter_type' during node deserialization

[ahmedelq]

Crash Report

Sometimes mypy crashes with a KeyError.

Traceback

Traceback (most recent call last):
  File "/home/user/project/.venv/bin/mypy", line 10, in <module>
    sys.exit(console_entry())
             ~~~~~~~~~~~~~^^
  File "/home/user/project/.venv/lib/python3.13/site-packages/mypy/__main__.py", line 15, in console_entry
    main()
    ~~~~^^
  File "mypy/main.py", line 127, in main
  File "mypy/main.py", line 211, in run_build
  File "mypy/build.py", line 191, in build
  File "mypy/build.py", line 267, in _build
  File "mypy/build.py", line 2939, in dispatch
  File "mypy/build.py", line 3330, in process_graph
  File "mypy/build.py", line 3408, in process_fresh_modules
  File "mypy/build.py", line 2096, in load_tree
  File "mypy/nodes.py", line 391, in deserialize
  File "mypy/nodes.py", line 4137, in deserialize
  File "mypy/nodes.py", line 4077, in deserialize
  File "mypy/nodes.py", line 252, in deserialize
  File "mypy/nodes.py", line 3498, in deserialize
  File "mypy/nodes.py", line 4137, in deserialize
  File "mypy/nodes.py", line 4077, in deserialize
  File "mypy/nodes.py", line 252, in deserialize
  File "mypy/nodes.py", line 968, in deserialize
  File "mypy/nodes.py", line 1132, in deserialize
KeyError: 'setter_type'

To Reproduce

The crash occurs consistently when running mypy on my project. Unfortunately, I haven't been able to isolate this to a minimal reproduction case yet, as it seems to be related to the specific combination of code patterns in my project. The error appears to be triggered during the deserialization of cached type information.

Steps that trigger the crash:

1. Run mypy app on the project
2. The crash occurs during the type checking process (not all the times)

Your Environment

• Mypy version used: mypy 1.16.0 (compiled: yes)
• Mypy command-line flags: none.
• Mypy configuration options from mypy.ini (and other config files): (please include your config)

[mypy]
python_version=3.13
strict_optional = True
show_column_numbers = True
check_untyped_defs = True
disallow_untyped_defs = True
warn_unreachable = True
warn_redundant_casts = True
mypy_path = /app
exclude = venv|.venv
plugins = pydantic.mypy
incremental = True
cache_dir = .mypy_cache

[mypy-pgvector.*]
ignore_missing_imports = True

[mypy-asyncpg.*]
ignore_missing_imports = True

• Python version used: 3.13
• Operating system and version: Debian GNU/Linux trixie/sid

[sterliakov]

This field was introduced in 1.16, and I don't see any obvious serialization/deserialization mismatches there. Please try to rename .mypy_cache folder and run mypy from scratch (so that it doesn't see the existing cache files) - does it fix the issue? I suspect some stale cache file somehow wasn't invalidated upon version upgrade.

[jhominal]

My colleague encountered the issue right after updating mypy, and we resolved the situation by deleting the .mypy_cache folder and rebooting the IDE.

I suspect that this was the result of the deserialization of a cache file from the previously installed version.

[sterliakov]

Good to have this confirmed, thanks! Now the question is why such files were actually deserialized - every cache mod.data.json file has a corresponding mod.meta.json that, among other fields, stores mypy version that generated it. If a meta produced by a different version is loaded, the cache file is recycled (mod.data.json is not loaded at this point):

mypy/mypy/build.py

Lines 1311 to 1319 in 34e8c7c

	# Ignore cache if generated by an older mypy version.
	if (
	(m.version_id != manager.version_id and not manager.options.skip_version_check)
	or m.options is None
	or len(m.dependencies) + len(m.suppressed) != len(m.dep_prios)
	or len(m.dependencies) + len(m.suppressed) != len(m.dep_lines)
	):
	manager.log(f"Metadata abandoned for {id}: new attributes are missing")
	return None

Since it only reproduces sometimes, I expect this bug to be quite interesting to catch. Any hints how to make it happen? I just ran mypy (1.15, then 1.16 with the same cache folder) on a bunch of codebases under my control, varying from Django to PyTorch to self-contained code with few dependencies, but can't reproduce:(