App Insights: Possibilities of initializing app insights with connection string and instrumentation key config

Question

I have a shared library that initialized app insights telemetry using an instrumentation key. A client had an issue with getting insights from the global endpoint, so Microsoft suggested switching to Connection String and also stated that I Keys would be deprecated by next year. I implemented logic in the shared lib to a initialize function as follows: if (!config.InstrumentationKey && !config.connectionString) throw error, and allow either an I Key or a Connection String in the configuration.

We have a large shell MFE (next.js 12) which dynamically imports other MFE (next.js) as well as an independent header MFE. I updated Shell and header to use Connection Strings. We deployed to test and both seemed to work sending track calls to proper endpoints using connection strings. Then when deployed to prod, upon further inspection during the release, after about a minute, QA found Shell would send some failed track requests trying to use a connection string when it expected an instrumentation key, then still calling the global endpoint (http://dc-services) instead of the Regional one and correct one (http://central-us).

I figured that this was happening because MFE within shell were still initializing with an Instrumentation key config and using a different version of the library and Microsoft docs clearly state to use one or the other.

Due to not being able to coordinate with multiple, global teams very suddenly, it was decided to temporarily hard code the connection strings in the library until all teams have migrated to connection strings, making another change in the library again change the initialize function only allowing a connection string, and grab the environment (dev, test, prod) out of the url params via a getConnectionString function. When deployed to dev a client side exception was thrown and no shell apps would render.

The shell and header are both next.js and the shared library is React, using Vite, and both store env variables respectively, next js using process.env.PUBLIC_NEXT_CONN_STRING and react/vite using import.meta.env.VITE_CONN_STRING. I thought this was the cause of not passing the hardcoded values within the library. I have since changed from purely writing the connection string as strings and storing them within an object which maps them to their respective environment, dev, test or prod. Has anyone dealt with this and knows a solution?

All teams will eventually need to migrate to connection strings, but this plan was put in place to avoid coordination efforts that have proved to be a challenge in the past.