mypy `mypy` crashes with `KeyError: 'type

Crash Report

mypy crashes.

Traceback

> mypy .
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "c:\Code\project\.venv\Scripts\mypy.exe\__main__.py", line 8, in <module>
  File "C:\Code\project\.venv\Lib\site-packages\mypy\__main__.py", line 15, in console_entry
    main()
  File "mypy\main.py", line 100, in main
  File "mypy\main.py", line 182, in run_build
  File "mypy\build.py", line 192, in build
  File "mypy\build.py", line 266, in _build
  File "mypy\build.py", line 2942, in dispatch
  File "mypy\build.py", line 3333, in process_graph
  File "mypy\build.py", line 3411, in process_fresh_modules
  File "mypy\build.py", line 2099, in load_tree
  File "mypy\nodes.py", line 399, in deserialize
  File "mypy\nodes.py", line 3945, in deserialize
  File "mypy\nodes.py", line 3886, in deserialize
  File "mypy\nodes.py", line 260, in deserialize
  File "mypy\nodes.py", line 3315, in deserialize
  File "mypy\nodes.py", line 3945, in deserialize
  File "mypy\nodes.py", line 3886, in deserialize
  File "mypy\nodes.py", line 260, in deserialize
  File "mypy\nodes.py", line 824, in deserialize
  File "mypy\types.py", line 224, in deserialize_type
    result.overwrite_doc = self.overwrite_doc
  File "mypy\types.py", line 2266, in deserialize
KeyError: 'type_is'

To Reproduce

I am sorry I do not have reproduction steps. This happened about 5 times across two days, and when it happened, it always fixed itself by running mypy 2 or 3 more times. (Maybe that invalidates the cache?)

Your Environment

Mypy version used: mypy 1.10.0 (compiled: yes)
Mypy command-line flags: none
Mypy configuration options from mypy.ini (and other config files):
Python version used: 3.12.3
Operating system and version: Windows 11 23H2

[tool.mypy]
strict = true

# https://github.com/pypa/setuptools/issues/3236
exclude = "build"

# https://github.com/matplotlib/matplotlib/issues/26942
untyped_calls_exclude = "matplotlib.dates.DateFormatter"

May 16 '24 06:05 bersbersbers

Yes, this is impossible to reproduce consistently. When I hit the issue, I can run mypy repeatedly, and it reproduces the same error many times. But as soon as I run mypy --cache-dir=nul, the issue is gone.

May 16 '24 06:05 bersbersbers

fwiw, ran into the same, reverting to 1.9.0 resolved it for me.

May 20 '24 21:05 cbadke

Ran into the same issue and also resolved by reverting to 1.9

May 31 '24 19:05 fennerm

I get it as well but it repro's every time.

Jun 21 '24 20:06 jabbera

@jabbera can you construct a reproducer?

Jun 22 '24 08:06 hauntsaninja

@hauntsaninja famous last words. Went to repro today and it didn't happen.

Jun 25 '24 16:06 jabbera

So, I could repro this occasionally, if I remove/add the #type: ignore[assignment, method-assign in a code that looks like this:

@pytest.fixture(name="mocked_service")
def fixture_mocked_service(
    mocker: pytest_mock.MockerFixture,
) -> services.SomeService:
    some_svc: services.SomeService = mocker.MagicMock(spec=services.SomeService)

    some_svc.process_something = mocker.MagicMock(
        side_effect=lambda _, something: models.Something( # type: ignore[assignment, method-assign]
            id=uuid.uuid4(),
            state=something.state,
            remote_url=something.remote_url,
            name=something.name,
            hash=something.hash,
            size=something.size,
            mime_type=something.mime_type,
        )
    )
    return some_svc

Unfortunately, this only fails if I run mypy on the entire project, so I cannot share a reproducible example since the code is proprietary. If I run mypy without the # type: ignore, I get the proper error, then when I run it after I add the # type: ignore it crashes.

The stacktrace is a bit different but fails at the same place

  File "/workspaces/hub-2/.venv/bin/mypy", line 8, in <module>
    sys.exit(console_entry())
             ^^^^^^^^^^^^^^^
  File "/workspaces/hub-2/.venv/lib/python3.11/site-packages/mypy/__main__.py", line 15, in console_entry
    main()
  File "mypy/main.py", line 100, in main
  File "mypy/main.py", line 182, in run_build
  File "mypy/build.py", line 192, in build
  File "mypy/build.py", line 266, in _build
  File "mypy/build.py", line 2942, in dispatch
  File "mypy/build.py", line 3333, in process_graph
  File "mypy/build.py", line 3411, in process_fresh_modules
  File "mypy/build.py", line 2099, in load_tree
  File "mypy/nodes.py", line 399, in deserialize
  File "mypy/nodes.py", line 3945, in deserialize
  File "mypy/nodes.py", line 3886, in deserialize
  File "mypy/nodes.py", line 260, in deserialize
  File "mypy/nodes.py", line 824, in deserialize
  File "mypy/types.py", line 224, in deserialize_type
    def gi_code(self):
  File "mypy/types.py", line 2266, in deserialize
KeyError: 'type_is'

This happens even if I annotate the fixture with @typing.no_type_check.

Jul 01 '24 03:07 assambar

Just started facing this issue with mypy==1.10.1 and updating to mypy==1.11.0 seems to have resolved the issue.

Jul 22 '24 20:07 olivierlefloch

I confirm that mypy==1.11.0 fixes the issue.

Jul 24 '24 14:07 ogabrielluiz

I'm still experiencing this error with mypy==1.11.0. Previously was on 1.9.0 and never had this issue. Can't create a reproducible example, and running itself again didn't solve the issue for me.

Environment

Mypy version used: mypy 1.11.0 (compiled: yes)
Mypy command-line flags: none
Mypy configuration options from mypy.ini (and other config files):
- ignore_missing_imports = true
- explicit_package_bases = true
- disallow_untyped_defs = true
Python version used: 3.11.6
Operating system and version: Windows 11 Pro 23H2

Jul 26 '24 13:07 viniciusbaca

`mypy` crashes with `KeyError: 'type_is'`