Fix TestsManifestGeneration tests #46658
Conversation
|
Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti Issue DetailsFix #46518 These tests sometimes fail because the call to disable the provider or roll over the file happens almost instantly after TraceEventSession.Flush(), and the Manifest data may not have been fully written to the file before we check for its existence. This adds a sleep between flushing and disabling the provider so that there's plenty of leeway for the payload to be fully written to the trace file.
|
...braries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestsManifestGeneration.Etw.cs
Show resolved
Hide resolved
|
Coming to this late, but could you not use the pattern of using a nominal (or no) sleep, doing the test, and if it fails, doing the longer sleep and testing again? This is the pattern we use many other places. Per the test history, we know that in the 99% case this sleep is not necessary. With the change as is, the tests all take longer to run, it's not a situation we want to be in. |
|
@danmosemsft thanks for the suggestion. So these sleeps were removed in a subsequent PR that addressed more issues on the test... But yes, I agree and I think we need to come up with a better synchronization mechanisms for the tracing tests as many of them are timing sensitive. |
ghost
locked as resolved and limited conversation to collaborators
Fix #46518
These tests sometimes fail because the call to disable the provider or roll over the file happens almost instantly after TraceEventSession.Flush(), and the Manifest data may not have been fully written to the file before we check for its existence. This adds a sleep between flushing and disabling the provider so that there's plenty of leeway for the payload to be fully written to the trace file.