Server components run twice during build and re-validation phase.

[1hemantbhatt]

Hi,

This topic is regarding the unclarity around the behaviour of app router's rendering which is noticed and mentioned on github issues(references at the bottom) quite a lot of time. Unfortunately there doesn't seem to be any definitive answers to it.

Before mentioning what this issue is, let me mention that this issue cannot be solved with disabling reactStrictMode.

The issue:

During the build and revalidation phase, all types of pages (SSG, SSR and ISR) have their code run twice.
This is specific to server components. Conversion to client components removes this issue.
A simple console.log statement of server component proves this.
Whenever you do 'npm run build', you can see each server component's log statement twice on the screen.

Code to test: (app/server_component/page.tsx)

export default async function Page() {
  console.log("This is a server component running.", Date.now());

  return <>Test component</>;
}

Terminal output during build:

This is a server component running. 1689846221524
This is a server component running. 1689846221580

The timestamp for both the logs are different meaning they were called at different times.
As soon as "use client" directive is used, this issue seems to go away. This points that this is only related to server components.

The same behaviour is observed during revalidation of a server component(their code runs twice).
Last checked that this behaviour still exists with 13.4.10.
It would be really helpful if we could know that whether this is an expected behaviour of server components and what is the reason behind the behaviour.

Similar issues:
#45551
#44966
#44655
#43158
#48722

[icyJoseph]

I think one collects HTML, the other collects RSC Props, or whatever that format is called.

If you create a second page (/about) and link / back to this second page. And take note of the timestamps you see.

import Link from "next/link";

export default async function Page() {
  const d = Date.now();
  console.log("This is a server component running.", d);

  return (
    <>
      Test component {d}
      <br />
      <Link href="/about">About</Link>
    </>
  );
}

And

// app/about/page.tsx
import Link from "next/link";

export default function About() {
  return (
    <>
      <h1>About</h1>
      <br />

      <Link href="/">Home</Link>
    </>
  );
}

And now build and run the app.

Generating static pages (0/6)
This is a server component running. 1689853369870
This is a server component running. 1689853369912

Navigating directly to / shows one timestamp, but navigating to / from /about yields the other one!

Test component <!-- -->1689853369870<br><a href="/about">About</a

You can see it in the network tab when you arrive to /about:

7:["Test component ",1689853369912,["$","br",null,{}],["$","$L8",null,{"href":"/about","children":"About"}]]

That timestamp is the second log I got while building.

[1hemantbhatt]

Hi,
Thanks for the quick reply.
This is very interesting.
So, what is the reason for having two variants of the same page.
Is it that 1st page is used for server-side routing and the other is used for client side routing (with next/Link or router.push ) ?

[icyJoseph]

Hard to write a case for it.

I could say that since render has to be Pure, it shouldn't matter, but at the same time, getting data from a network request is impure, and even though fetch caches most things, one could easily end up with such data divergence.

In Pages router, if I remember correctly, the data you passed to the page as props, was reused, to the point where mutating the data could result in errors.

• getInitialProps Circular structure error, but I'm not using getInitialProps! #47135 (reply in thread)

Maybe this is a TODO, optimisation kind of thing?

Edit

But yeah, I forgot to answer your question. I do believe one pass is rendering the HTML string, and the second pass is creating that RSC format thing.

[1hemantbhatt]

And you are right, getting data is indeed impure.
Even though fetch is caching most things, what happens if we use some kind of a third party client that does not use fetch internally to get data.
In that case there will be data divergence and there can be 2 different versions of the page if 2 different requests in a time gap yield 2 different response.

This way the user will see 2 different pages based on their routing behaviour.

[1hemantbhatt]

I wonder why a single server component run cannot be used to do both, collect html and create the rsc format thing that is visible in network tab.
Like, what is the main reason behind this paradigm.

[icyJoseph]

I haven't really inspected much of the code around app router rendering. I can image that it is "just" a current implementation issue. It has been only some months since they released this.

I could also imagine that they do some transformations or mutations to the data generated from a render pass, and to prevent having to deep clone the entire thing, they just recreate the render pass. I am speculating of course.

[shweta-codeprism]

Any further update on this? The issue is with the data fetch, with two different renders, we can indeed have two different version although they are invoked very close to each other. And its also expensive, if we have a good range of dynamic parameters. Two data calls per SSG page.

[DiiiaZoTe]

This to me is a serious issue and should definitely be looked at.
My personal issue I have with this is for ISR, if your endpoint does not always return the same data.

In the example below, I replace the data fetching by a random number.

export const dynamicParams = false;
export const revalidate = 3600;

export const generateStaticParams = async () => [
  { collection: "one" },
  { collection: "two" },
];

export default async function Page({
  params,
}: {
  params: { collection: "one" | "two" };
}) {

  const collection = params.collection;
  console.log("Rendering my-page", collection);

  const randomNumber = Math.random();
  console.log("randomNumber", randomNumber);

  return (
    <div>
      <h1>Page {collection}</h1>
      <p>{randomNumber}</p>
      <Link href="/my-page/one">One</Link>
      <Link href="/my-page/two">Two</Link>
    </div>
  );
}

Build log

Rendering my-page one
randomNumber 0.07447778317905396
Rendering my-page one
randomNumber 0.6416512959466623
Rendering my-page two
randomNumber 0.4424228671365247
Rendering my-page two
randomNumber 0.8359440870214472

If I navigate to page one then I see 0.6416512959466623. When I navigate client side to page two I get 0.4424228671365247.
If I refresh page two I see 0.8359440870214472, and then navigate client side to page one I see 0.07447778317905396.

So no matter what I do will always get two sets of results/pages depending on where the routing originated at.
It is a stretch I know... but it's a pain to work around.

[1hemantbhatt]

It's interesting that this is still the behavior and is still not fixed. What this implies is that if your server component function is anything other than pure function then you will have 2 different variants of the same page.
One client page and one server page.

Where this can be not at all optimal is a list of posts that gets delivered through an API call. If the list refreshes too often, then the client and server pages can be significantly different.

[DiiiaZoTe]

Exact!
In my use case it's an api endpoint that returns pretty much the same data, but often times changes the order of the items it returns. Meaning that each variant will have a different orderering of the data... Not optimal at all.

[alivarastepour]

Same issue here with the following setup:

  "dependencies": {
    "next": "15.0.0-rc.0",
    "react": "19.0.0-rc-f994737d14-20240522",
    "react-dom": "19.0.0-rc-f994737d14-20240522"
  },

I created a test API which returned a random number. According to docs, the request is expected to be triggered only once when used separately both in a layout and in a page(with the same layout); but that's not what happens. The generated numbers in the layout and in the page are different. IDK if this is an issue with React or Next though.