0.0.1-alpha.22 is hanging

[galah92]

Summary

Looks like something related to the search path.
Attached run logs on the same codebase with alpha.21 and alpha.22.

0.0.1-alpha.21.log
0.0.1-alpha.22.log

Version

No response

[MichaReiser]

The 0.22 log only contains a single message saying that all checks passed.

Would you mind running ty with ty check -v or even ty check -vv? Is the project available open source (we could then try to run ty ourselves).

[galah92]

My bad, attached the updated log:

• uvx ty@0.0.1-alpha.21 check -vv 2> 0.0.1-alpha.21.log: 0.0.1-alpha.21.log
• uvx ty@0.0.1-alpha.22 check -vv 2> 0.0.1-alpha.22.log: 0.0.1-alpha.22.log

You'll notice 0.22 has many types_aiobotocore_* not found in search paths.

[MichaReiser]

I can see that the performance significantely recreased between 21 and 22 (from ~100ms to 4s).

The logs otherwise look mostly the same, including the many failed module resolutions.

It's a bit hard to tell from the logs which file took long to type check. We should probably add some timing information to our logs to make it easier to track those down.

For the failed imports: Is /Users/galah92/Downloads/VayyarHomeCloud/python your virtual environment? Are the dependencies that fail to resolve installed into that environment?

[galah92]

For the failed imports: Is /Users/galah92/Downloads/VayyarHomeCloud/python your virtual environment? Are the dependencies that fail to resolve installed into that environment?

Yes, that's the root of my repo. I cannot share the code unfortunately. All dependencies were resolved correctly, alpha.21 seem to find them all.
Is there anything else I can provide that will help to debug this?

[MichaReiser]

Yes, that's the root of my repo. I cannot share the code unfortunately. All dependencies were resolved correctly, alpha.21 seem to find them all.

I'm not sure about that. I see about the same amount of unresolved import errors for both versions (at least from the logs you shared).

Is there anything else I can provide that will help to debug this?

I put up astral-sh/ruff#20836 which should help debug this in the future. What you could try now is to run the following command (assuming unix):

TY_MAX_PARALLELISM=1 ty check -vv

This reduces concurrency to 1 thread. The timing events in the logs should then tell us which file takes long to type check (unless there are multiple once). Once you konw the file, you can try to binary-search your way to find the problematic code:

• Try to comment out half of the imports.
  • Is it still slow? Try to comment out the other half of the imports... and so on
  • Is it now fast? Revert, now comment out the other half of the imports...
• After the imports, apply the same mechanics to the body of the file. Comment out half of the file's body. Is it still slow? Comment out the half of the remaining uncommented code...

Hopefully, this narrows the code down to a single Class, method, or a few lines. You could then try to obfuscate the code before sharing or try to describe the problematic code (like what is it doing? Is it a large dictionary or type dict, is it a very large union? ...)

I'm sorry that there isn't an easier way.

We're also aware of some cases where ty is hanging (e.g. does your code look similar to #1111) that we hope to address as part of the next release. You could also consider waiting and reporting back with the new release (should be released sometimes this week)