FWIW, I couldn't actually reproduce this with (inside the Zulip directory):

rm -rf var/mypy_cache
git checkout 09f66b5c6dfc5c8bf5d52fb51259189ade0f336e^
tools/run-mypy
git checkout 09f66b5c6dfc5c8bf5d52fb51259189ade0f336e
tools/run-mypy

Yeah the missing info is all the mtimes of the files in Tim's working directory when it failed. :-(

(FWIW if this occurs again on an open source package, as of mypy 0.521 the mtimes in the .mypy_cache directory are no longer a problem, as we now use a hash of the source file.)

I think @hackerkid saw this earlier today in the Zulip project; but we may be a bit behind 0.521 (haven't updated since PyCon).

I got the error after I switched from a branch invite-link which had the model MultiUserInvitation to the branch get-user-2g which didn't had the model. But interestingly I was not able to reproduce the error when I switched from invite-link to master. I tried the switching multiple times and was able to obtain the same behavior. All the branches were rebased on top of upstream/master.

During each switch I did

• ./tools/provision
• ./tools/run-mypy

I have attached the tar of my Zulip directory including the cache here.

Update: fixed the get-user-2g-link. Thanks ethanhs

(the correct get-user-2g link)

@hackerkid did this happen consistently? Could you try updating the version of Mypy that you use? It appears your version is old.

I downloaded the tarball but could not repro the issue with mypy 0.521, so I think it's not worth looking into further. Let us know whether you still see this with master.

Hmm, I've definitely seen this since 0.521. I just upgraded to the latest mypy master in case that helps; will let you know when I next see it (it's about once a week, usually after a series of switches between branches including one that deletes things).

If and when you see it, tarring up your entire zulip tree (.git and all) like @hackerkid did would be very helpful.

We've seen a similar crash internally, where the assert referenced a class that was deleted by the change. Sadly it was also impossible to repro. Which means that at least the work-around of deleting the cache shouldn't be too painful.

An internal user claims this can be reproduced as follows:

0. Start with a clean slate
1. Run mypy
2. Make an edit
3. Run it again, with -i
4. Revert the edit (e.g. git stash)
5. Run it again, with -i -- BOOM

The edit in step 2 could be a whitespace edit, as long as it's a type-checked file.

@gvanrossum I now have a simple repro for this crash inspired by #4043. Here is the recipe:

Initial setup:

# a.py
from b import x

# b.py
from c import x

# c.py
x = 1

with any previous mypy caches removed. Steps to reproduce:

• run mypy a.py
• delete (or comment out) definition of x in c.py
• run mypy -i a.py (it will show an obvious error)
• add random whitespace to a.py
• run mypy -i a.py again -- AssertionError: Cannot find x for c.x

Thanks! Adding an unused variable definition to a.py in the 4th step will work too. I've also confirmed that this crash was introduced by the same PR (#2014) that caused #4043. I haven't played with fixes yet.