Repository navigation
RequestIds in PostExecutionStart/Stop events are not unique for different call stacks #1302
Description
Bug description
PostExecutionStartEvent and PostExecutionStopEvent both contain a request ID. Users should be able to uniquely identify the events based on the request Id and correlate the start/stop event pairs for processing.
In our performance testing, we found out that sometimes different tasks had same request ID. Here is a snapshot of the events:
These events have the same id but from the call stacks of the Start events, they are clearly not from the same task.
Metadata
Metadata
Assignees
Labels
No labels
Activity
AArnott commentedon Apr 18, 2024
The requestId comes from calling
object.GetHashCode()on a unique object. I believe the default implementation of this method returns something based on its memory address, so that's pretty wild that you found cases where the same address happens to be used for the same type of object but unique instances across time.I expect we could use an interlocked incrementing integer to ensure uniqueness.
Ensure unique `requestId` values in ETW events
davkean commentedon Apr 19, 2024
Note, it's an int not a long so it needs to truncate the address, so it could be two addresses. But the chances of that still seem super slim for the same type of object?
weltkante commentedon Apr 19, 2024
Looking at the code the current PR replaces, when NonConcurrentSynchronizationContext is installed as current SC its post method uses the hash of its SendOrPostCallback - a caller controlled delegate in public API is not guaranteed to be unique, in fact Roslyn will try to cache and reuse it wherever possible. (If its never installed/visible to external code this way its not an issue of course.)