Provide the dependency ID when tracking dependencies

[stijnmoreels]

Is your feature request related to a problem? Please describe.
When tracking dependencies, we should include an dependency ID so the later request tracking can use it for its parent operation ID in a service-to-service correlation scenario.

Describe the solution you'd like
We should include an dependencyId to all our available dependencies. This will usually result in method extension overloads.

Additional context
https://github.com/arcus-azure/arcus-service-to-service-correlation-poc

The dependency ID should be added to the following dependency types as extensions overloads:

• Azure Key Vault (@stijnmoreels, feat: add dependency ID to az key vault dependency tracking #251 )
• Azure search (@stijnmoreels, feat: add dependency id to az search #345 )
• Azure Service Bus Queue (@stijnmoreels feat: add dependency id to az servicebus queue tracking #348 )
• Azure Service Bus Topic (@stijnmoreels feat: add dependencyid to az servicebus topic dep tracking #360)
• Azure Service Bus (general) (@stijnmoreels feat: add dependency id to az servicebus queue tracking #348 )
• Azure Blob storage (@stijnmoreels feat: add dependency id to az blob storage dep tracking #370)
• Azure Table storage (@stijnmoreels feat: add dependency id to az tabe storage dep tracking #371)
• Azure Event Hubs (@stijnmoreels feat: add dependency id to event hubs dep tracking #378)
• IoT Hub (@stijnmoreels feat: add dependency id to iot hub dep tracking #379 )
• Cosmos SQL (@stijnmoreels feat: add dependency id to cosmosdb dep tracking #380)
• HTTP dependency (@stijnmoreels feat: add dependency id to http dep tracking #373)
• SQL dependency (@stijnmoreels feat: add dependency id to sql dep tracking #376 )
• Custom dependency (@stijnmoreels feat: add dependency id to custom dep tracking #362)

[stijnmoreels]

As mentioned, we should maybe return the dependency ID when calling .LogDependency so the caller can use the ID somewhere else (like in a HTTP request header).

[tomkerkhove]

The problem is, you will only track the dependency after the request so you have to generate the dependency ID up front and pass it when tracking the dependency so that you can send it to your downstream service.

[stijnmoreels]

The problem is, you will only track the dependency after the request so you have to generate the dependency ID up front and pass it when tracking the dependency so that you can send it to your downstream service.

That's maybe the responsibility of the consumer.

[tomkerkhove]

As mentioned, we should maybe return the dependency ID when calling .LogDependency so the caller can use the ID somewhere else (like in a HTTP request header).

Certainly, but you have to allow them to generate and provide it. If you only return it as suggested here it will not work

[stijnmoreels]

Should we actually add this dependency ID to very dependency call we already have? This means doubling our current set of dependency calls (both with and without a dependency measurement). I'm wondering if it's better to work with options that we can more easily expand.

[tomkerkhove]

Should we actually add this dependency ID to very dependency call we already have? This means doubling our current set of dependency calls (both with and without a dependency measurement).

Yes that is the case, or it could be an optional parameter but then we can have conflicts again so overloads might be best suited

I'm wondering if it's better to work with options that we can more easily expand.

Options are great but add some friction in my opinion as it would make the code more verbose, IMO, but I'm happy to consider it. Would you mind posting a sample?

[stijnmoreels]

logger.LogBlobStorageDependency(
    "<account-name>",
    "<container-name>",
    options =>
    {
        options.IsSuccessful = true;
        options.StartTime = DateTimeOffset.UtcNow;
        options.Duration = TimeSpan.FromSeconds(10);
        options.DependencyId = "<dependency-id>";
    },
    context: new Dictionary<string, object> ());

[tomkerkhove]

This is more verbose imo but I don't have a strong opinion - @fgheysels @gverstraete ?

[stijnmoreels]

Let's keep it as it is, for now. The signature is already complex enough, no need to further complicate it.

[fgheysels]

I'm not sure if I'm following the use case here. Maybe we can have a short call on this @stijnmoreels ?

[fgheysels]

@stijnmoreels do we continue with this ?
In my opinion, HttpDependency should have priority here. (It is required to be able to convert the service-to-service correlation poc project to fully rely on Arcus).

[stijnmoreels]

Yes, we continue with this. Was taking this between other work now and then.

[stijnmoreels]

Great, this monster 👾 of an issue is finally done!