BUG: Telemetry 'Call status' is false for a 304 response for refresh key after moving to v7.0.0 from v6.0.1

[GrievousAngel]

After upgrading the nuget package from version 6.0.1 to 7.0.0 response telemetry is incorrectly setting the 'Call status' to false and therefore application maps show it as a failing request.

Previously this was being set to true:

Previous (6.0.1)

Current (7.0.0)

[amerjusupovic]

Hi @GrievousAngel, from what I've gathered, it's unlikely that the API version is the cause of this change in call status. If possible, I'd like to get a better understanding of your situation. Did you change anything else between these two screenshots other than the version of the nuget package, and which package was it? Also, does this happen for every request and does it go back to true whenever you downgrade the App Configuration version?

[GrievousAngel]

@amerjusupovic, there was also a minor bump in the ApplicationInsights packages from 2.21.0 to 2.22.0

• Microsoft.ApplicationInsights
• Microsoft.ApplicationInsights.AspNetCore
• Microsoft.ApplicationInsights.EventCounterCollector
• Microsoft.ApplicationInsights.WorkerService

I can try rolling those back and isolating the change to solely the Microsoft.Azure.AppConfiguration.AspNetCore package and see if they were the cause. I'll report back.

[GrievousAngel]

I have isolated the changes to just the Microsoft.Azure.AppConfiguration.AspNetCore package and it does seem to suggest it is the cause in the behavioural difference. The below screen shot shows the history of an application requesting a refresh of the app config, our key is call 'Sentinel Key'.

12:47-12:58 using v7.0.0
13:07-13:41 using v6.0.1
13:46-13:52 using v7.0.0

[amerjusupovic]

I was able to reproduce this on my end, and I've noticed that specifically on 304 requests I also get False. I was able to isolate this change to a dependency that was updated going into the 7.0.0 release, and I'm investigating this to understand more of what's going on and to see if this was an intentional change. I'll update this issue once I know more. Thank you for your patience!

[amerjusupovic]

@GrievousAngel Just to update those involved, I showed the Application Insights team how to reproduce the issue and they were able to narrow down where they believe the issue is within the Azure.Data.AppConfiguration package. They should be investigating this now, so I'll keep up with any updates to see when this will be fixed and released.