@Lisenish It's due to Next.js started preloading the entries since v15 (related PR: #65289). We can fix this behavior on our side. But I'd like to learn what's the real-world case you're relying on this behavior? Cause the global side effects in page could execute in a lot of places either in static build or now in entry preloading. It sounds risky to me to rely on the contract that. Curious what are you doing with relying on the execution order of instrumentation and the page.

Hello @huozhi, thanks for looking into this! (and I see you even have a draft PR for this!)

Yes, I suspected this was due to the preloading. I also understand your point, and I agree global side-effects are dangerous and probably not the best practice it's better to avoid them, agree completely 👍

With this issue I mainly wanted to highlight that IMHO Next 15 has silently introduced a breaking change with this new behavior, and ideally it should be either fixed or we need to update the docs (even though it was only experimental in Next 14).

Why is it a breaking change? Please correct me if I'm wrong but I think it was always assumed that instrumentation.ts runs before everything else, because that is actually the requirement of many instrumentation tools to run before anything else in the app. Also, I think currently even the official docs suggest this as a place to work with side effects (see https://nextjs.org/docs/app/building-your-application/optimizing/instrumentation#importing-files-with-side-effects).

I think you understand if I change the register in my MRE repo to something like:

await loadSecrets();
await import("./global-side-effect-file");

it still won't change the behavior, the global side effect will run before instrumentation's loadSecrets in Next 15 (let me know if you want me to create an actual branch in MRE).

If Next team thinks the current behavior is the correct one and won't fix then IMHO we should add a note to Next 15 changelog and update the above docs.

Now let me still describe our use case here at the end if you're still curious (IMHO we shouldn't focus on it here since there could be other cases among other users).

Our Use Case

It's actually somewhat similar to what I did in MRE:

• We have our own dotenv wrapper which allows users to specify GCP Secret Manager URL as environment variable value (something like MY_SECRET=sm://my_secret#version1) in env files without exposing the secrets.
• We call this wrapper in instrumentation.ts to actually replace the above values with actual secrets from GSM, so actually the rest of the app can still work with env vars as usual without worrying about fetching and caching the secrets (just in case: yes these are server side only secrets)
• There were other unrelated files in the app with side effects which used the above environment variables with secrets
• Due to this issue in Next 15 instead of actual values we caught a sneaky bug when these files started to use raw sm://my_secret#version1 values instead of actual secrets since side effects executed before the instrumentation and cached the raw value before secrets were initialized in instrumentation

We of course, refactored the side-effect part to get rid of it, since we wanted to upgrade to 15 without waiting for the official patch, but it actually required some effort since we have many web apps and we needed to do the same fix across all of them.

@huozhi Thank you for the quick fix! 🙇 (just in case also confirmed it works now in MRE with the latest canary)