Skip to content

Conversation

@AlexWaygood
Copy link
Member

In #20937, we reduced this from 20 to 5, so that it would become obvious if ty was now taking a pathological amount of time to type-check a given seed. 5 minutes is easily long enough if there are no new bugs, but it turns out to be too low if there are new bugs, because on encountering a new bug the fuzzer must repeatedly run ty on a smaller and smaller snippet in order to try to minimize the reproducible example. That means that the fuzzer job is timing out on #20962, not because of pathological performance issues but because we're not giving the script enough time to minimize the bugs that it's found.

Hopefully 10 should be a good compromise where it still becomes obvious if we introduce pathological performance issues on certain fuzzer seeds, but we give the fuzzer enough time to minimize examples when it finds new bugs.

A better solution to find new pathological performance issues on fuzzer seeds might be to just compare the execution time between the baseline-executable run on a given seed and the test-executable run on the same seed. This is just a quick-and-easy fix for now.

In #20937, we reduced this from 20 to 5, so that it would become obvious if ty was now taking a pathological amount of time to type-check a given seed. 5 minutes is easily long enough if there are no new bugs, but it turns out to be too low if there _are_ new bugs, because on encountering a new bug the fuzzer must repeatedly run ty on a smaller and smaller snippet in order to try to minimize the reproducible example. That means that the fuzzer job is timing out on #20962, not because of pathological performance issues but because we're not giving the script enough time to minimize the bugs that it's found.

Hopefully 10 should be a good compromise where it still becomes obvious if we introduce pathological performance issues on certain fuzzer seeds, but we give the fuzzer enough time to minimize examples when it finds new bugs.

A better solution to find new pathological performance issues on fuzzer seeds might be to just compare the execution time between the baseline-executable run on a given seed and the test-executable run on the same seed. This is just a quick-and-easy fix for now.
@AlexWaygood AlexWaygood added ci Related to internal CI tooling ty Multi-file analysis & type inference labels Nov 2, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Nov 2, 2025

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

@sharkdp
Copy link
Contributor

sharkdp commented Nov 2, 2025

Thanks

@AlexWaygood AlexWaygood merged commit bff32a4 into main Nov 2, 2025
40 checks passed
@AlexWaygood AlexWaygood deleted the fuzz-timeout branch November 2, 2025 02:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci Related to internal CI tooling ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants