Test_BadEventSource_MismatchedIds failing on CI

[hoyosjs]

Can't create tracking issue, see: https://runfo.azurewebsites.net/search/tests/?q=started%3A%7E7+definition%3Aruntime+name%3ATest_BadEventSource_MismatchedIds

cc: @dotnet/dotnet-diag

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Can't create tracking issue, see: https://runfo.azurewebsites.net/search/tests/?q=started%3A%7E7+definition%3Aruntime+name%3ATest_BadEventSource_MismatchedIds

cc: @dotnet/dotnet-diag

Author:	hoyosjs
Assignees:	-
Labels:	area-System.Diagnostics.Tracing, blocking-clean-ci
Milestone:	-

[josalem]

Is there any way to see timestamps in the runfo data? When did this start failing?

[josalem]

runtime/src/libraries/System.Diagnostics.Tracing/tests/BasicEventSourceTest/TestsUserErrors.cs

Line 136 in 0c20095

Assert.Equal(Guid.Empty, ea.ActivityId);

@noahfalk did anything change in the activity ID generation logic recently? I'll go take a look at the error path for this.

The test is expecting an error to be generated because the EventSource has a mismatched ID in the WriteEvent call, e.g.,

public void Event1() => WriteEvent(1, "foo");
public void Event2() => WriteEvent(1, "foo");

The test seems to be passing until it checks some of the details on the event that came in. The error message is correct, but it is expecting empty GUIDs rather than the activity IDs it is getting.

[hoyosjs]

This is odd. Looks like before 7/15 they were failing in another way. After that it's the guid mismatch. That seems to match #55625

Query

TestResults 
| where Method == "Test_BadEventSource_MismatchedIds" and Result == "Fail" and Message contains "Assert"
| distinct JobName, WorkItemName, Message
| join (WorkItems | where Queued > ago(30d) | project-away JobId, WorkItemId) on JobName, $left.WorkItemName == $right.Name

[noahfalk]

The only change I know of that directly modified ActivityIDs was #55625 that Juan mentioned. It is also possible that something changed in the test harness to create additional activities, or something changed in the logging to enable the TPL provider (which causes activity ID tracking to be enabled).

The test doesn't appear to take any steps to prevent ambient activity IDs from being present so I'd consider this a test bug, fixable by either eliminating the check or setting the expected value to EventSource.CurrentThreadActivityID.