Re-enable IdenticalSubmissionsShouldCompleteAndNotHangTheBuildOnMissingTargetExceptions #9253
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ladipro
force-pushed
the
reenable-test
branch
from
b1a78bc to
63a7237
Compare
YuliiaKovalova
approved these changes
Sep 27, 2023
Forgind
approved these changes
Oct 6, 2023
|
Possibly idea from MiYanni: Defender also seems plausible, though 🙂 |
bulatgrzegorz
pushed a commit
to bulatgrzegorz/selective-condition-evaluator
that referenced
this pull request
Oct 16, 2023
…ngTargetExceptions (dotnet#9253) Fixes dotnet#9245 Context The test was disabled to unblock PR CI. Changes Made Increased the relevant timeout. Testing The test is reliably passing now. Notes This turned out to be an issue with the sleep command we use on Windows. In some cases PowerShell can take a super long time to start. I have been able to reproduce locally by enabling Fusion logging. Thread times of the powershell process: image We spend almost 10 seconds just loading assemblies, so the timeout of 10 seconds for the entire build was not enough. I don't have a full understanding of the mechanism that slows down PowerShell this much. At this point I'm happy we were able to confirm it's not a product issue, although I'm wondering if there is a better and more light-weight sleep command we could use on Windows instead (e.g. ping 127.0.0.1 -n <seconds>). Reviewers please opine. EDIT: In my trace, file system operations block extensively with wdfilter.sys on the stack, so the likely explanation for the issue appearing all of a sudden is a Defender update.
MichalPavlik
pushed a commit
that referenced
this pull request
Oct 17, 2023
…ngTargetExceptions (#9253) Fixes #9245 Context The test was disabled to unblock PR CI. Changes Made Increased the relevant timeout. Testing The test is reliably passing now. Notes This turned out to be an issue with the sleep command we use on Windows. In some cases PowerShell can take a super long time to start. I have been able to reproduce locally by enabling Fusion logging. Thread times of the powershell process: image We spend almost 10 seconds just loading assemblies, so the timeout of 10 seconds for the entire build was not enough. I don't have a full understanding of the mechanism that slows down PowerShell this much. At this point I'm happy we were able to confirm it's not a product issue, although I'm wondering if there is a better and more light-weight sleep command we could use on Windows instead (e.g. ping 127.0.0.1 -n <seconds>). Reviewers please opine. EDIT: In my trace, file system operations block extensively with wdfilter.sys on the stack, so the likely explanation for the issue appearing all of a sudden is a Defender update.
This was referenced Jul 29, 2025
Closed
Closed
This was referenced Oct 15, 2025
Closed
Open
This was referenced Oct 26, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Fixes #9245
Context
The test was disabled to unblock PR CI.
Changes Made
Increased the relevant timeout.
Testing
The test is reliably passing now.
Notes
This turned out to be an issue with the sleep command we use on Windows. In some cases PowerShell can take a super long time to start. I have been able to reproduce locally by enabling Fusion logging. Thread times of the
powershellprocess:We spend almost 10 seconds just loading assemblies, so the timeout of 10 seconds for the entire build was not enough.
I don't have a full understanding of the mechanism that slows down PowerShell this much. At this point I'm happy we were able to confirm it's not a product issue, although I'm wondering if there is a better and more light-weight sleep command we could use on Windows instead (e.g.
ping 127.0.0.1 -n <seconds>). Reviewers please opine.EDIT: In my trace, file system operations block extensively with
wdfilter.syson the stack, so the likely explanation for the issue appearing all of a sudden is a Defender update.