Disable test parallelization in installer tests #58604
Conversation
|
Tagging subscribers to this area: @vitek-karas, @agocke Issue Detailsnull
|
| private TestProject CopyTestProject(TestProject sourceTestProject) | ||
| { | ||
| // This can race with the filesystem. If we're running this code from two threads, fail fast |
There was a problem hiding this comment.
Even with test parallelization disabled, does xunit guarantee it'll always run tests on the same single thread? I'd have expected it'd be valid for it to run tests on different threads, just serialized.
There was a problem hiding this comment.
It doesn't guarantee it as far as I can tell, but it happens to work for now.
I'm not particularly pleased with this solution, but it's the closest thing I can find to a workaround that will scream if something goes wrong.
Long term plan needs to be to make these tests thread safe
There was a problem hiding this comment.
@stephentoub Any suggestions? If this starts failing I can remove the lock
There was a problem hiding this comment.
I wonder if this fails when xunit is allowed to run concurrently and whether the tests really touch the same files.
There was a problem hiding this comment.
I am concerned that we are not dealing with concurrent use of the same file issue. If we do not realy have that, then change may have effect, but only because it makes tests to run slower or smth and would only reduce failures, not eliminate them.
There was a problem hiding this comment.
What I suspect is the root cause is that in rare cases the file system has not finished writing the executable and we already try executing it. I do not know though how to prove this or how to prevent this from happening.
There was a problem hiding this comment.
What I find suspicious is that bundle tests are not the only tests which write executables and then try to run them immediately after. Lot of the hosting tests do this - they either build the app and immediately run it, or in some cases we take a built app, patch the apphost and then run it (patching it to enable some test features in the product).
The only main difference between the hosting tests and the bundle tests is the size of the executable. Hosting tests use the standard apphost (150KB), while the bundle tests create large single-file executables (60MB+).
So it is definitely possible that the file system didn't really finish writing it yet. Or there's some other thing (like AV) taking longer due to the size of the file. It's also interesting that pretty much all the failures are on Linux.
|
Decided to not go forward with this, found other fixes instead. |
ghost
locked as resolved and limited conversation to collaborators
Should help #53587