Closed rossgrambo closed 4 months ago
Met with Zhenlan offline. My takeaway is:
Our current preview release is placing TargetingId on the RequestTelemetry. However Split is not reading RequestTelemetry today, so it's not currently helpful to experimentation to be on there.
Should we be setting TargetingId on RequestTelemetry at all?
If the answer is no- then this PR is not the correct way to solve this problem and we should use a cache. If the answer is yes- this PR is a valid way to persist the TargetingId to custom events without needing a cache.
Currently I'm on the fence if we should add it. It's not helpful to split yet- but it could be helpful in App Insights today. If we go with "no" and pursue a caching solution instead, would adding TargetingId to RequestTelemetry 6 months from now make the cache obsolete? If so, our caching solution better not be a breaking change to take away.
Should we be setting TargetingId on RequestTelemetry at all?
Comparing to the current way (putting it in httpcontext.items), I will vote for setting TargetingId on RequestTelemetry, since it is the recommanded way in App Insights docs.
I am bit on the fence regarding whether we should add TargetingId to RequestTelemetry because we don't have any out-of-box usage scenario for RequestTelemetry today, but I'm not opposed to it. It could be handy for customers if they want to correlate feature evaluation with request telemetry. Of course, it could be handy for customers if we add TargetingId to all other ASP.NET telemetry (e.g. performance counters). I almost feel we should give customers an option to opt-in/out.
Regardless of whether we add TargetingId to RequestTelemetry (and other ASP.NET telemetry), it doesn't feel right to use RequestTelemetry as a caching mechanism in the middleware. We already have an initializer, and we must add TargetingId to the custom events. Even if we want to add TargetingId to RequestTelemetry (and any other ASP.NET telemetry), we should add it in the initializer.
I agree, customers should probably be able to opt out of it. And if that's something we might offer- we would still need the custom events to be populated with it. I think that's a good argument for decoupling these. Going to close this PR.
I agree, customers should probably be able to opt out of it. And if that's something we might offer- we would still need the custom events to be populated with it. I think that's a good argument for decoupling these. Going to close this PR.
This PR moves the middleware into the asp.net core project though. Will you be opening a new PR for that?
Yes I will. Going to solidify the shape of the caching first- since it has implications on what projects the middleware depends on.
For example, with the changes in this PR- it made a lot of sense to place the middleware under App Insights. I want to make sure that's still the case after changes.
Why this PR?
Primarily a refactor. Also resolves https://github.com/microsoft/FeatureManagement-Dotnet/issues/424. Related to- but explicitly not resolving here since the middleware was moved out of the main AspNetCore package https://github.com/microsoft/FeatureManagement-Dotnet/issues/396.
ITargetingContextAccessor
is async and could not used reached byITelemetryInitializer
. We currently get around this by having our middleware addTargetingContext
toHttpContext
so it can be read synchronously.This PR adjusts the middleware to instead place
TargetingId
on theRequestTelemetry
object instead. This object is specific to Application Insights and we were already addingTargetingId
to it with our existing initializer. By adding this earlier, we allow the initializer to depend on this field rather than the key onHttpContext
. It also allows us to simply use the "TargetingId" key, rather than having a custom one forHttpContext
.This also allows
ITargetingContextAccessor
to cache however it wants and we're not caching in multiple places.In short: Middleware stores on RequestTelemetry instead of HttpContext. Initializer now simply moves fields from RequestTelemetry to other Telemetry (like custom events).
Visible Changes
HttpContext
will no longer have the key "Microsoft.FeatureManagement.TargetingId" added toHttpContext.Items
.