StopOperation reports telemetry that is not in current scope

[lmolkova]

see #644 (comment).

var firstOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 1");
var firstTask = RunMyTaskAsync();

var secondOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 2");
var secondTask = RunMyTaskAsync();

await firstTask;

// Must not be tracked, but it is
telemetryClient.StopOperation(firstOperation); 

await secondTask;

tried running the above example with firstOperation and secondOperation, and for me telemetry for task1 is still logged (after logging an error "Operation to stop does not match the current operation"). Looking at the code for OperationHolder.Dispose() it seems like the return statement on line 86 only returns from ActivityExtensions.TryRun(), but not from Dispose(). isActivityAvailable is true, so the second return is never called either, and the operation gets logged successfully.

Even if telemetry is reported, some of its properties may be initialized from the System.Diagnostics.Activity (.NET tracing context that is used by AppInsights) during Track() by SDK or custom TelemetryIntitializer. As the Activity.Current is no longer correct and represents another operation, so reported telemetry under some conditions will be incorrect.

[TimothyMothra]

This is affecting some customers;

AI (Internal): Operation to stop does not match the current operation.

• AI (Internal): Operation to stop does not match the current operation #693

• Unexpected Trace “AI (Internal): Operation to stop does not match the current operation”

Do we have a work around to provide customers?
@Dmitry-Matveev has suggested disabling Diagnostics Module.

[lmolkova]

@MS-TimothyMothra
the only known reason for it is when StartOperation/StopOperation are called incorrectly from the user code (e.g. see example in the issue description).
More on this here

For now, the only place Start/StopOperation are called by the SDK is .NET Core Http listener.
If we would know for sure the problem is there, we can dig more into this and see if there is an issue with the listener.

The potential impact of this issue: wrong correlation that is hard to notice. The trace helps to understand that something is wrong, so I find it useful.

I'll get in touch with the customer in #693 to help narrow the root cause.

[nerdile]

If other folks are landing here because their events are not showing up, and they are seeing the trace "Operation to stop does not match the current operation. Telemetry is not tracked." - make sure that you are not overwriting the operation.Telemetry.Id field between StartOperation and StopOperation.

And if your failure events are not showing up in AppInsights, make sure that anytime you set Success = false, you also set a ResponseCode value. Otherwise, the service seems to silently drop these events.

In hindsight, it seems obvious, but as someone with an existing request correlation system, trying to onboard to AppInsights for the first time, it seemed natural to put my own existing Request ID into that field.