Flaky test: `tests/ui/threads-sendsync/tcp-stress.rs`

[Zalathar]

Test tests/ui/threads-sendsync/tcp-stress.rs sometimes fails for reasons unrelated to the changes being tested.

Examples:

• Rollup of 13 pull requests #144850 (comment)
• Shard AllocMap Lock #136115 (comment)
• Fix HashMap not displaying correctly in VS debugger #93626 (comment)

The failure is triggered by an arbitrary hard-coded timeout of 30 seconds, so this probably happens when the runner is temporarily distracted by other things and can't clean up 200 threads in time.

[jieyouxu]

Interesting... this test was last modified (in a meaningful way) like ~9 years ago.

[jieyouxu]

It should be fine to just turn down the size of this tests, it was originally meant to stress libuv and turn up bugs, but that's long gone now!

-- #35107 (comment)

Could we get away with chopping the thread count (e.g. from 200 to 100)?

[ChrisDenton]

Tbh I'm not really sure how useful this test is if the goal was to just test tcp. It's mostly a thin wrapper around OS APIs so it seems like we're effectively just testing the OS's implementation rather than testing rust.

[jieyouxu]

#144894 would downsize it from 200 -> 100, but we could also just yeet the test if that's acceptable.

[ChrisDenton]

It would probably be good to get a second opinion from t-libs. cc @the8472 maybe?

[Zalathar]

If we do keep the test, I would want to greatly increase the timeout, so that there's much less risk of it randomly torpedoing an entire CI run.

But given that this sort of test is a poor fit for tests/ui anyway, I would be happy to see it deleted.

[the8472]

Digging through the git history... 65cca4b is the commit that originally introduced the test. It was a regression test for a fix to detect a UAF in libuv use. Since we don't use libuv anymore it's no longer serving its purpose. +1 to yeeting.