In the deployment environment revalidation request does not work in ‘/’ page

[heeeete]

Link to the code that reproduces this issue

https://github.com/heeeete/qqq

To Reproduce

There is a component on the ‘/’ path that displays products, and the request is sent as follows:

const getRecentProducts = async () => {
  try {
    const baseUrl = process.env.NEXT_PUBLIC_BASE_URL;
    const res = await fetch(`${baseUrl}/api/products/recent`, {
      next: { tags: ['products'], revalidate: 10 },
    });
    if (!res.ok) {
      console.error('API request failed:', res.status, res.statusText);
      throw new Error('Failed to fetch products');
    }
    const data = await res.json();
    console.log('HELLO = ', data);
    return data;
  } catch (error) {
    console.error('Error occurred while executing getRecentProducts function:', error);
    throw error;
  }
};

export default getRecentProducts;

Additionally, on the ‘/sell’ page, the API makes the following revalidation requests:

export async function POST(req) {
    revalidateTag('products');
    revalidatePath('/');
    revalidatePath('/shop');
    revalidatePath(`${process.env.NEXT_PUBLIC_BASE_URL}/`);
    revalidatePath(`${process.env.NEXT_PUBLIC_BASE_URL}/shop`);
}

At first, I tried only revalidateTag('products'); but the revalidation request did not work. Then I added revalidatePath('/'); and revalidatePath('/shop');, and when that didn’t work, I added revalidatePath(${process.env.NEXTAUTH_URL}/); and revalidatePath(${process.env.NEXTAUTH_URL}/shop);.

Despite these attempts, the ‘/’ page data remains the same as it was during the build. The revalidate: 10 revalidation option also does not work.

Even router.refresh() is not working on the ‘/’ page, while it works fine on other pages.

However, everything works fine in the local development environment. In the deployment environment using
next run build and next run start
revalidation does not occur no matter what.

Additionally, we are using React Query, but even with staleTime = 0, it always fetches the previous data in CSR. This issue also occurs only on the ‘/’ page.

import { connectDB } from '@/lib/mongodb';
import { NextResponse } from 'next/server';

export const dynamic = 'force-dynamic';

export async function GET() {
  try {
    const client = await connectDB;
    const db = client.db(process.env.MONGODB_NAME);
    const products = db.collection('products');
    const recentProducts = await products
      .find({ $or: [{ state: 1 }, { state: 2 }] })
      .sort({ createdAt: -1 })
      .limit(5)
      .toArray();
    return NextResponse.json(recentProducts, { status: 200 });
  } catch (error) {
    return NextResponse.json({ error: 'Internal Server Error' }, { status: 500 });
  }
}

When force-dynamic is added to the top of the route.js file, revalidation occurs on the ‘/’ path in sync with the revalidation timing of other pages. Why is this happening?

Current vs. Expected behavior

Main Page Revalidation Request Not Working

Expected Behavior:
When the function
revalidateTag('products'); is executed, all requests using the ‘products’ tag should be revalidated.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Fri Jul  5 17:56:41 PDT 2024; root:xnu-10063.141.1~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 22.3.0
  npm: 10.8.1
  Yarn: 1.22.19
  pnpm: 8.14.0
Relevant Packages:
  next: 14.2.5 // Latest available version is detected (14.2.5).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed)

Additional context

No response

[github-actions]

We cannot easily recreate the issue with the provided information. Please add a minimal reproduction in order for us to be able to help more efficiently.

Why was this issue marked with the please simplify reproduction label?

There was a reproduction provided, but due to its complexity, we cannot easily reproduce the issue.

An ideal minimal reproduction (unless relevant):

• is not part of a monorepo
• does not require secrets to run
• does not reference private registry dependencies
• has as few dependencies as possible
• excludes unrelated pages/routes
• does not require a database/third-party service to run
• only includes the code necessary to reproduce the issue
• is tested against next@canary to make sure your issue has not already been fixed

In general, assume that we should not go through a lengthy onboarding process at your company code only to be able to verify an issue.

If you cannot create a clean reproduction, another way you can help the maintainers' job is to pinpoint the canary version of next that introduced the issue. Check out our releases, and try to find the first canary release that introduced the issue. This will help us narrow down the scope of the issue, and possibly point to the PR/code change that introduced it. You can install a specific version of next by running npm install next@<version>.

What happens if I don't provide a sufficient minimal reproduction?

Issues with the please simplify reproduction label that receive no meaningful activity (e.g. new comments with a simplified reproduction link) are automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue with the required reproduction.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Providing a minimal reproduction from the start without asking helps us look into issues much more quickly, as we can easily verify if the reported bug is related to Next.js. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.