-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider re-trying when connecting to a host #3494
Comments
I'm having issues at the moment with some refactoring and now my UWP Test app won't work anymore. I'm getting the timeout message, but have no idea why it won't connect to the app (I see the UWP app launching still). I don't see a host log or anything, and I can't even debug in VS, so I have no idea where to get more info or know what the problem is. I can set breakpoints if I try and debug the UnitTest app directly, but that doesn't work the same from the text explorer. It looks like there's some verbose tracing available in the Any pointers would be appreciated to make these scenarios more understandable when the UWP host fails to reach back to the client and make the connection for testing to continue. |
This is a new feature and won't be implemented, we are focusing on adding new features to Testing.Platform instead. https://aka.ms/testingplatform |
Description
Usually vstest.console is the host, and it starts testhosts that are a clients. But when UWP does remote deployment, then testhost is started as host, and vstest.console is client.
Client connection is attempted immediately after host process is started, which is usually not a problem. But there is race condition between how fast testhost can start, and when we try to connect to it. When testhost is slow to start up, or if we attach debugger to it, the client connection gets refused ("silently"), and ends up timing out.
This is in log:
But this is what user ends up seeing after waiting 90 seconds:
Steps to reproduce
Have remote uwp test run, and automatically attach debugger to the testhost, and add breakpoint on startup.
Expected behavior
Client will retry using some retry policy. Or will show the error and immediately fail.
Actual behavior
The error is basically invisible, debugger breakpoints need to be set code that is after connection setup. User has to wait for the timeout to happen.
The text was updated successfully, but these errors were encountered: