Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Activity Based TargetingId Persistance #467

Merged
merged 4 commits into from
Jul 5, 2024

Conversation

rossgrambo
Copy link
Contributor

Why this PR?

  1. Switches our Middleware and Initializer to use Activity.Baggage instead of HttpContext.Items to store Targeting information.
  2. Removes the Microsoft.FeatureManagement.ApplicationInsights.AspNetCore package

Visible Changes

The Microsoft.FeatureManagement.ApplicationInsights.AspNetCore will no longer be a nuget package deployed. The initializer has moved to Microsoft.FeatureManagement.ApplicationInsights.

Migrating

Developers using the initializer will need to change their using statement from

using Microsoft.FeatureManagement.ApplicationInsights.AspNetCore

to

using Microsoft.FeatureManagement.ApplicationInsights

There are no changes to the line that adds the initializer or anywhere else. This line stays:

builder.Services.AddSingleton<ITelemetryInitializer, TargetingTelemetryInitializer>();

…atureManagement.Telemetry.AspNetCore project
@jimmyca15
Copy link
Member

Removes the Microsoft.FeatureManagement.ApplicationInsights.AspNetCore package

I don't see any files removed in the diff

}

// Telemetry.Properties is deprecated in favor of ISupportProperties
if (telemetry is ISupportProperties telemetryWithSupportProperties)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a case that this wouldn't be true, perhaps if a user used an old version of app insights?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is no, that they will always be available. The deprecation message for telemetry.Properties says:

TelemetryContext.Properties is obsolete. Use GlobalProperties to set global level properties. For properties at item level, use ISupportProperties.Properties.

They were added in v2.21.0. .NET 6 and above should use at least v2.21.0, so I think we can assume this will be available. The versions before that are all deprecated (actually including v2.21.0 as well). v2.22.0 is the latest.

@rossgrambo
Copy link
Contributor Author

Updated to remove Microsoft.FeatureManagement.Telemetry.ApplicationInsights.AspNetCore

@rossgrambo
Copy link
Contributor Author

Any other concerns?

@@ -50,14 +53,15 @@ public async Task InvokeAsync(HttpContext context, ITargetingContextAccessor tar

if (targetingContext != null)
{
context.Items[TargetingIdKey] = targetingContext.UserId;
var activityFeature = httpContext.Features.Get<IHttpActivityFeature>();
activityFeature?.Activity?.AddBaggage(TargetingIdKey, targetingContext.UserId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The null check on activity feature is a safeguard, but it's still unexpected right? I'm thinking we should log a warning if it's null.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjusted to:

var activityFeature = httpContext.Features.Get<IHttpActivityFeature>();

if (activityFeature == null)
{
    _logger.LogDebug("The IHttpActivityFeature from the IFeatureCollection was null");
}
else if (activityFeature.Activity == null)
{
    _logger.LogDebug("The Activity on the IHttpActivityFeature was null");
} else
{
    activityFeature.Activity.AddBaggage(TargetingIdKey, targetingContext.UserId);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a debug log. You don't consider it worth a warning?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following suit on the other null check that causes the middleware to no op:

    _logger.LogDebug("The targeting context accessor returned a null TargetingContext");

But I suppose these two are more unexpected than that one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I suppose these two are more unexpected than that one?

Yes, I would say that. And also I believe we didn't want to log warning in the middleware for not having a targeting context because the idea was to consider the middleware may be in use even if targeting is not enabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR: #471

@rossgrambo rossgrambo merged commit c8deb66 into preview Jul 5, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants