We now have StartOperation and StopOperation TelemetryClient extension methods to track custom operations.

While it's pretty useful and flexible, typical scenario requires customer to write something like

    var operation = telemetryClient.StartOperation<RequestTelemetry>("name");

    try
    {
        await DoWorkAsync();
        operation.Telemetry.Success = true;
    }
    catch (Exception e)
    {
        telemetryClient.TrackException(e);
        operation.Telemetry.Success = false;
        throw;
    }
    finally
    {
        telemetryClient.StopOperation(operation);
    }

This approach potentially has an issue with execution context: it may not be preserved between Start/Stop, so the operation may not be tracked at all.
All above code except DoWorkAsync has nothing to do with user code.

Proposal

Introduce new TelemetryClient extensions methods:

• async Task TrackWorkAsync( Func<Task> work, Activity activity=null)

• async Task TrackWorkAsync( Func<Task> work, OperationTelemetry telemetry)

• other necessary overloads

These methods would do the same as above example does.

Real world scenario

I'm working on the queues instrumentation and majority of queue clients (Azure Storage Queue, EventHub, certain ServiceBus usage scenarios) have API to receive a message(s) from the queue but do not include API to process a message.

I. e. if dependency tracing is implemented, AppInsights then would track 'receive' call to the queue, but message processing should be instrumented manually.

Queues will provide method to extract Activity from the messages, so customers are expected to write code

var message = queue.Receive();
var activity = message.ExtractActivity();

telemetryClient.TrackWork( () => DoWorkAsync(), activity );

@SergeyKanzhelev @Dmitry-Matveev @TomMilos thoughts?