[ty] Increase timeout-minutes to 10 for py-fuzzer job #21196
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.