unhandledRejection: Error: NEXT_NOT_FOUND on terminal after running npm run dev about next-intl

[ptts]

@amannn We figured it out: We called useLocale in serverside code which - for some reason - used to work fine before 3.14 but now throws an error. Now we're using await getLocale() and everything works fine again. 👍🏼

[amannn]

A reproduction would be important to look into this, but based on the stack trace, it could be that your error is caused by this misconfiguration: Unable to find locale. You should see an error message pointing towards this on the console though.

[ptts]

I also currently can't provide a lot of information but we just had to hotfix rollback next-intl from 3.14.0 to 3.13.0 as a big part of our app (NextJS, App Router, RSC, TRPC) was completely broken:

Frontend:

Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.

Backend:

a [TRPCClientError]: Suspense Exception: This is not a real error! It's an implementation detail of `use` to interrupt the current render. You must either rethrow it immediately, or move the `use` call outside of the `try/catch` block. Capturing without rethrowing will lead to unexpected behavior.

To handle async errors, wrap your component in an error boundary, or call the promise's `.catch` method and pass the result to `use`
    at a.from (/var/task/apps/web/.next/server/chunks/8292.js:1:1194)
    at /var/task/apps/web/.next/server/chunks/8292.js:5:1545 {
  meta: undefined,
  shape: undefined,
  data: undefined,
  digest: '3877659871',
  [cause]: Error: Suspense Exception: This is not a real error! It's an implementation detail of `use` to interrupt the current render. You must either rethrow it immediately, or move the `use` call outside of the `try/catch` block. Capturing without rethrowing will lead to unexpected behavior.

We've never had this issue before.
Rolling back to next-intl 3.13 fixed it immediately. (the only change we committed which fixed the issue)

Might me able to provide more information after Tuesday.

[amannn]

Interesting. If you could provide some more information or ideally a reproduction, that would be helpful.

There was another report about 13.14, we were able to resolve that: #1072

[ptts]

I can't provide a full reproducable example but maybe an excerpt of the code might help to show what we're using:

import { notFound, redirect, RedirectType } from "next/navigation";
import { getTranslations } from "next-intl/server";
import { api } from "~/trpc/server";

async function getData(id: string) {
  try {
    return await api.getData.query({
      id,
    });
  } catch (error) {
	// this had some more logic to check for a not found error in this case we called "notFound()"
    throw error;
  }
}

export default async function Page({
  params,
}: {
  params: { id: string };
}) {
  const { id } = params;
  const data = await getData(id);

  if (data.isComplete) {
    redirect("/different/path", RedirectType.replace);
  }

  const t = await getTranslations();

  return <div>// ... component that uses t</div>;
}

This code never resulted in any problems before upgrading to 3.14

Thanks for taking a look!
Let me know if I can provide anything else that might be of help

[amannn]

I don't see an issue with that code. Can you try to isolate the issue to a particular line that causes the issue? Can you also post your i18n.ts?

[ilikali]

My application works in the following way. I have two locales "default", "ru". In case the user has changed the locale, I use it the next time he visits the site (I use a cookie to switch the locale before rendering in the middleware file). Here is my middleware.ts file

import createIntlMiddleware from "next-intl/middleware";
import { NextRequest, NextResponse } from "next/server";

export default async function middleware(request: NextRequest) {

  const handleI18nRouting = createIntlMiddleware({
    locales: ["default", "ru"],
    defaultLocale:
      request.cookies.get("lang")?.value &&
      request.cookies.get("lang")?.value == "ru"
        ? "ru"
        : "default",
    localePrefix:
      request.cookies.get("lang")?.value &&
      request.cookies.get("lang")?.value == "ru"
        ? "always"
        : "as-needed",
    localeDetection: false,
  });
  const response = handleI18nRouting(request);

  const locale =
    response.headers.get("x-middleware-request-x-next-intl-locale") ||
    "default";

  response.cookies.set("lang", locale == "default" ? "az" : locale, {
    expires: new Date(new Date().getTime() + 90 * 24 * 60 * 60000),
  });

  return response;
}

export const config = {
  matcher: ["/((?!_next|.*\\..*).*)", "/([\\w-]+)?/profile/(.+)"],
};

Here is my i18n.ts file:

import { notFound } from "next/navigation";
import { getRequestConfig } from "next-intl/server";

const locales = ["default", "ru"];

export default getRequestConfig(async ({ locale }) => {
  if (!locales.includes(locale as any)) notFound();

  return {
    messages: (await import(`../messages/${locale}.json`)).default,
  };
});

[amannn]

@ilikali Were you able to figure out a solution eventually?

"default" is in any case not a valid locale. The locale is not only used for reading messages, but also for formatting dates, etc.

I'm wondering why you have to do these gymnastics in the middleware? It seems like what you need is localePrefix: 'as-necessary', why can't you declare the two locales your app supports in the regular way, as it's shown in the docs and examples?

[ilikali]

@amannn I’ll try to explain why I’m facing such a dilemma. The fact is that my website uses two locales: Azerbaijani and Russian. However, the site also has pages that start with "/az", meaning "/az/[slug]" - where "az" is not a locale in the URL of the page. Therefore, I had to rename the "az" locale to "default", and then use code to check if the "default" locale is selected to simulate a call to the "az" locale. I understand this sounds very complex, but these are the realities of my project.