-
Notifications
You must be signed in to change notification settings - Fork 199
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
Integration test fixes, skips and logging #9201
Conversation
Just cleaning things up before I go looking for log messages
Logging the project key intead of the filename makes it easier to understand what is going on. For the configuration state change, since the changes are debounced, it wasn't clear when any event would actually be applied.
This seems to resolve the issue with the zip file being corrupted. Also included more log files because I wasn't convinced we were getting them all
Now that the output window uses a queue, to avoid threading issues, we were missing some logs as tests fail. This allows our integration tests to hook into the output window logging and ensure we capture it all directly into the test output. What this means in practice is being able to download the one test run log file, and have it contain the full log for any failing test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was only used in O#
It looks like sometimes web tools hangs on getting code actions, but when that happens instead of just one test failing, the whole run would have to wait 20 minutes, then time out. This made identifying the failure much more difficult. Hopefully this helps, if it doesn't, we'll probably need to add our own timeout.
The custom message target infra in the platform doesn't support partial results, and we were getting multiple semantic tokens requests that seems like maybe they overlapped. Both of these are purely speculative changes
We get lots of these at the same time
Code folding is one of the earliest LSP requests we get, and unlike semantic tokens we don't have an opportunity to tell the client we are ready to answer them. Hopefully a wait and a text change will improve the tests.
7f46328
to
e0a02a0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome logging additions + fixes!!
@@ -220,4 +227,44 @@ private static void WaitForFileExists(string file) | |||
Thread.Sleep(100); | |||
} | |||
} | |||
|
|||
private static void WaitForFileFinishedWriting(string file) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yessss so glad to have the LogHub logs uncorrupted! 👏 Is there a validation run that confirms this works in CI? A while ago I think I tried something similar with File.Open
and was still seeing the corrupted logs, but my overall implementation was a bit different which could have affected things
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This run is a failure from this branch which should prove it works: https://dev.azure.com/dnceng-public/public/_build/results?buildId=391392&view=artifacts&pathAsName=false&type=publishedArtifacts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit-at-a-time review recommended, the changes are mostly unrelated anyway.
Been pouring over integration test logs yesterday and this is the result of what I have found.
Problems I found:
Fixes I made:
I would love to do more with the LogHub logging, to get it to make more sense and include the custom message logs as part of the LSP request that caused them, but I lack the knowledge of LogHub for how to do that at the moment.