[BUG] Manually defined ai.location.city and ai.location.province are overriden by real geolocation data

[developerMCSI]

Description/Screenshot We followed the example shown in https://github.com/microsoft/ApplicationInsights-JS/issues/1360 to mask the city and the province. We create a custom event to track gamification answer. In some cases the override works and in others it doesn't

Steps to Reproduce TypesScript code:

    const snippet: Snippet = {
      config: {
        instrumentationKey,
      },
    };
    this.applicationInsights = this.applicationInsightsFactoryService.create(snippet);
    this.applicationInsights.loadAppInsights();
    this.applicationInsights.addTelemetryInitializer((envelope: ITelemetryItem) => {
      envelope.tags[CtxTagKeys.locationCountry] = 'masked country';
      envelope.tags[CtxTagKeys.locationProvince] = 'masked province';
      envelope.tags[CtxTagKeys.locationCity] = 'masked city';
    });

Expected behavior

• City => "masked city"
• State or province => "masked province"
• Country or region => "masked city"

Additional context The code is still the same, but this is what we see

[MSNev]

I believe that the server replaces the City / State as part of removing the client ip address, I'll check with them to see if there was a recent change or a way to stop overwriting any provided details.

[thomasp-ms]

Just stumbled upon this and I believe I'm experiencing a similar issue, except in my case the telemetry is sent through the opencensus-ext-azure python SDK.

[MSNev]

Very likely, as this appears to be occurring on the server side where it's getting replaced on ingestion.

[seekingtheoptimal]

I have a bit different "issue" with location, but not sure where to open it @MSNev maybe you can point me in the right direction? I am intercepting some http requests with a cloudflare worker, and I track custom events from this interception into ai. I want to have location data, so to not loose the original client IP, I made a telemetry initializer that sets the "ai.location.ip" envelope value explicitly (otherwise all requests would be geolocated based on the ip of the intercepting worker). This works, however it gives different values when giving ipv4 vs ipv6 addresses. According to the docs, ai uses the GeoLite2 lookup, which I have tried and even for my ipv6 address gives correct city, but in application insights it stops at the country level, and does not give city information for my ipv6 address. If I hardcode my ipv4 address into the envelope then I also get the city as expected. Any clue why the result is different in ai, even though the GeoLite2 lookup contains all necessary info both for ipv4 and ipv6? I've read also in the docs that for browser telemetry the ip is registered at ingestion side, but it seems that when providing it manually up front, it behaves inconsistently. (I also thought maybe it is just an older GeoLite2 database, but it is refreshed weekly so I have doubts that it is something so trivial, assuming MS always uses the latest lookup table)

[MSNev]

I've reached out to the internal team for some guidance as I don't know the answer myself atm.

[MSNev]

@seekingtheoptimal I have the following response from the internal team that owns this.

Currently, they are using an un-updated version of GeoLite2 and it leads to the discrepancies mentioned. As such that are working on a custom implementation of IP Lookup. It will use the latest map of IP locations with automatic updates.

[seekingtheoptimal]

thank you @MSNev in this case it makes sense