`fetch` requests triggered by `revalidateTag()` are not logged

[sgwrangler]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/q3xjfg

To Reproduce

My steps are in with dynamicIO enabled but it also doesn't work without it.

1. Set up a fetch function that uses a tag for caching:

export const getData = async () => {
  'use cache';
  cacheTag('example-tag');
  cacheLife('seconds');

  return fetch('https://example.com/api/data', {
    method: 'GET',
  });
};

2. Create an action or route handler that revalidates the tag:

'use server';

import { revalidateTag } from 'next/cache';

export async function revalidateExampleTag() {
  revalidateTag('example-tag');
}

3. Call the revalidation action from another component:

// app/page.tsx or app/components/Trigger.tsx
'use client';

import { revalidateExampleTag } from '../actions';

export default function Page() {
  return (
    <button onClick={() => revalidateExampleTag()}>
      Revalidate
    </button>
  );
}

Current vs. Expected behavior

Current

When calling revalidateTag() in a Next.js app (App Router), any fetch() requests that are internally triggered as part of the revalidation are not logged in the terminal

Expected

fetch() requests triggered by revalidateTag() should be logged in the terminal like any other server-side fetch call

Provide environment information

"next": "15.4.0-canary.75",

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

dynamicIO

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

next dev (local)

Additional context

https://github.com/user-attachments/assets/8ec7eacc-f041-46a4-acf4-a884c49e7531

[poorvasingh04]

I am wondering why are you using next.js internal apis. Have you tried this -

export const getData = async () => {
  return fetch('https://example.com/api/data', {
    method: 'GET',
    next: {
      tags: ['example-tag'],  
      revalidate: 60,
    }
  });
};

[sgwrangler]

@poorvasingh04 I am not sure which internal API you are referring to. revalidateTag, "use cache", cacheLife nor cacheTag are internal APIs

[ermakovich]

We are also experiencing this issue. The worst thing is that fetch requests triggered by revalidation are NOT cached during server action execution/rendering phase. Cache will be fulfilled ONLY during next visit to the page. In our case this results into TONS of extra requests being sent to our api, since we are relying very heavily on caching in our components.

[gnoff]

Confirmed the logging is not working. We will fix but don't have an ETA

The worst thing is that fetch requests triggered by revalidation are NOT cached during server action execution/rendering phase.

when cacheComponents is enabled fetches are not cached automatically. Even inside a "use cache" function the thing you are caching is the function output not the inner fetches. If you want to additionally cache the fetches you can wrap each fetch in it's own "use cache" with a longer cacheLife or a separate cacheTag. Additionally all the other ways fetches can be cached in Next.js should still work ({ cache: 'force-cache'} or { next: { revalidate: ... } }, etc...)

[ermakovich]

@gnoff

Additionally all the other ways fetches can be cached in Next.js should still work ({ cache: 'force-cache'} or { next: { revalidate: ... } }, etc...)

I'm not sure whether it is an issue in NextJS, or React Server Components, but it seems that fetch requests are not deduplicated during server action execution, despite that they are explicitly tagged with cache: 'force-cache'. I just tested with Canary with this logging issue fixed, and I clearly see unexpected requests in the log now. Will try to report a separate issue with repro. Here is a screenshot of the log for now:

[unstubbable]

The (hard refresh) indicates that you likely have the "Disable cache" checkbox checked in your browser's dev tools. In this case Next.js explicitly bypasses caches.

[ermakovich]

The (hard refresh) indicates that you likely have the "Disable cache" checkbox checked in your browser's dev tools. In this case Next.js explicitly bypasses caches.

@unstubbable nope, this is not related to dev tools. We had this issue on production with users complaining about performance of server actions, and it turned out to be issue with redundant fetches blocking response of server action. Below is a screenshot of log with complete GET - POST (server action) cycle for the same route. Unwanted extra requests are outlined with red color.

[unstubbable]

May I ask you to create a new issue with a repro then, so that we can have a closer look at what's going on in your specific case?

[ermakovich]

yep, will do. Thank you.

[github-actions[bot]]

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.