Repository: next.js
Issue: [Local Build] API routes that use `revalidate`cannot be revalidated
Labels: bug

### Link to the code that reproduces this issue

https://github.com/markomitranic/nextjs-api-route-invalidation-bug

🤞 Here is a simplified version. The following code will revalidate every `60` seconds, but won't revalidate when `revalidateTag("currentTime");` or `revalidatePath("/api/currentTime");` are invoked:

```ts
// api/currentTime/route.ts
export const revalidate = 60;

export async function GET() {
  const currentTime = await fetch("http://worldtimeapi.org/api/timezone/Europe/Copenhagen", {
    next: { tags: ["currentTime"] },
  });

  return NextResponse.json({ currentTime: await currentTime.json() });
}
```

### To Reproduce

1. Clone the repository
2. Run `pnpm install && pnpm build && pnpm start`
3. Open the following pages:
   1. [/api/currentTime](http://localhost:3000/api/currentTime)
   2. [/api/currentTimeFetch](http://localhost:3000/api/currentTimeFetch)
   3. [/api/currentTimeTagged](http://localhost:3000/api/currentTimeTagged)
4. Opening [/api/revalidateApiResponse](http://localhost:3000/api/revalidateApiResponse) should force both API responses to be revalidated, but it does not. Refresh the other pages and observe the time.
5. (Bonus points) Open [http://localhost:3000/](http://localhost:3000/) page and try using the server action to do the same revalidation. It also has no effect on the opened tabs.

### Current vs. Expected behavior

If an API route has a `revalidate` setting, it is cached for that amount of time. This works well.

Running a `revalidatePath` or `revalidateTag` through another API route or a server action should forcefully clear the cache of the API route - even if the `revalidate` TTL is not yet finished.

It seems to work fine in the dev server (obviously, since it mostly skips cache) as well as when deployed to Vercel production.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:14:38 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6020
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.13.1
  npm: 10.5.2
  Yarn: 1.22.22
  pnpm: 9.1.2
Relevant Packages:
  next: 14.3.0-canary.81 // Latest available version is detected (14.3.0-canary.81).
  eslint-config-next: N/A
  react: 19.0.0-beta-04b058868c-20240508
  react-dom: 19.0.0-beta-04b058868c-20240508
  typescript: 5.1.3
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 build (local), next start (local)

### Additional context

I also tested this on the latest current `"^14.2.1"`.

The reproduction repository shows examples with:
- Just `revalidate = 60`
- `unstable_cache` usage and `revalidate = 60`
- `fetch` Next tags usage and `revalidate = 60`

This differs from the App router `page.tsx` behaviour as well as the Vercel deployment behaviour, where a `revalidation` number seems to have a lower priority than a tag or path revalidation. 

I haven't found any documentation to explain it, so I believe it to be a bug in the local server.