Server Translation not working if client use Grafana Faro

[bozzelliandrea]

Description

When using Grafana Faro, which is a client side observability tool for react application, next-intl stop working only for server side components
and print on server side console the following error
Error: MISSING_MESSAGE: No messages were configured on the provider.

if you remove the faro component from the reproduction URL example, it works.

Verifications

• I've verified that the problem I'm experiencing isn't covered in the docs.
• I've searched for similar, existing issues on GitHub and Stack Overflow.
• I've compared my app to a working example to look for differences.

Mandatory reproduction URL

https://github.com/bozzelliandrea/next-faro-intl

Reproduction description

• add faro configuration (if using example, you can skip the configuration and ignore connectin error client and server side)
• create a next client side component with faro initialization (already in the example)
• add faro component to layout.tsx (already in the example)
• run install and run next application
• switch locale from the default to another one (ex. switch from /en to /it)
• check server side console log (translation not working but middleware find locale and json mapping)
• removing FaroComponent and then the i18n works as expected with multiple locales

Expected behaviour

Localization working with Grafana Faro when switching locale.

[amannn]

I had a brief look at your example and can confirm there's a really weird bug here. As this happens as soon as you add Faro, maybe you want to investigate with them? I'm not sure if they do anything funky like modifying Next.js internals or so, the behavior looks unlike anything I've seen before honestly.

[github-actions]

Thank you for your report!

From the currently available context in this issue, it's unclear wether the erroneous behavior is caused by Next.js, next-intl or a 3rd party library that you're using. Please isolate the issue further to be sure that the issue is caused by next-intl. When in doubt, please search on the Next.js issue tracker or related resources of 3rd party libraries you might be using.

If you're able to isolate the issue to next-intl, please provide a minimal reproduction that ideally doesn't involve any 3rd party libraries or alternatively demonstrates that next-intl is causing the issue.

Thank you for your understanding!

[SalmenBejaoui]

After debugging the provided repo, it seems the issue is caused by OpenTelemetry that Faro uses internally. OpenTelemetry overrides the Promise object internally using Zone.js https://github.com/angular/zone.js/blob/master/lib/common/promise.ts#L490

After the first render and Faro initialisation, the promise retrieved by getConfig seems not to be a native promise, skipping resolving the promise and retrieving the messages object because result instanceof Promise = false

https://github.com/amannn/next-intl/blob/main/packages/next-intl/src/server/react-server/getConfig.tsx#L75.

[amannn]

Oh wow, thanks for digging into this @SalmenBejaoui!

I found this in the Zone.js docs:

While still a supported part of Angular, the Angular team strongly discourages using Zone.js outside of Angular application contexts.

However, since it's used as part of OpenTelemetry, the Next.js docs recommend this package and it is very popular, maybe out of pragmatism next-intl could provide a workaround for Zone.js for the time being.

Let me have a look …

[amannn]

I've added #1719 to address this (pre-release available as next-intl@0.0.0-canary-84fe6d0).

It seems like it fixes the error in your reproduction. Can you confirm that this version works for you?