Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

revalidateTag() not functioning as expected in versions above 14.2.10 when used directly in page.tsx #70403

Closed
JesperCph opened this issue Sep 24, 2024 · 5 comments · Fixed by #70446
Labels
bug Issue was opened via the bug report template.

Comments

@JesperCph
Copy link

Link to the code that reproduces this issue

https://github.com/JesperCph/revalidate-tag-issues-reproduction

To Reproduce

  1. Build and start the app using pnpm build & pnpm start
  2. Open the app at http://localhost:3000/
  3. Time is fetched from /api/time, displayed on the landing page, and cached for 60 seconds with the tag time.
  4. Navigate to the "Revalidate (page)" using the link, which triggers revalidateTag('time').
  5. Navigate back to the "Home" page ('/'), should fetch the updated time from /api/time and display the new value.

Issue
This workflow works as expected in [email protected] and below, but in versions above 14.2.10, including next@15, the tag "time" is not revalidated on visiting /revalidate/page.tsx

Callen revalideTag() within a POST server action, works as exspexted. This can be tested by clicking
Revalidate (Form Action) from the home page, which updates the time.

Current vs. Expected behavior

Current:
The time on the home page / is not updated when navigating back and forth between /revalidate and / using the links.

Expected:
The time on the home page / should update with the value from /api/time when navigating back and forth between /revalidate and / using the links, as the revalidateTag('time') function is called from /revalidate/page.tsx.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Fri Mar 29 23:14:13 UTC 2024
  Available memory (MB): 15813
  Available CPU cores: 20
Binaries:
  Node: 19.9.0
  npm: 9.6.3
  Yarn: 1.22.22
  pnpm: 8.15.6
Relevant Packages:
  next: 14.2.13 // Latest available version is detected (14.2.13).
  eslint-config-next: 14.2.13
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.6.2
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 start (local)

Additional context

  • The bug was introduced in [email protected].
  • When calling revalidateTag() within a POST server action, the time is revalidated as expected.
@JesperCph JesperCph added the bug Issue was opened via the bug report template. label Sep 24, 2024
@markedwards
Copy link

I have also observed revalidateTag() seemingly being ignored in a GET route handler, as of [email protected]. In my case, the handler returns a stream which is consumed by the EventStream API, and the revalidation occurs in a stream handling callback when the stream is about to conclude. So its not exactly a vanilla case, but it worked fine up until 14.2.11.

I haven't fully debugged it, but could it be a related issue?

@abhi12299
Copy link
Contributor

abhi12299 commented Sep 25, 2024

@markedwards can you provide a reproduction repo?

@markedwards
Copy link

@markedwards can you provide a reproduction repo?

I haven't narrowed it down yet, and the actual repro involves setting up a page with an EventStream, and building a stream. It's a bit too complicated. Will dig in to it further, but this issue caught my eye as potentially related.

@janvdhorst
Copy link

janvdhorst commented Sep 26, 2024

i am also encountering errors on my use server function that I did not get before and i can't figure out where they come from

Failed to get by tag TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received an instance of Array
at new NodeError (node:internal/errors:405:5)
at validateString (node:internal/validators:162:11)
at Object.join (node:path:1171:7)
at zu (file:///var/task/frontend/index.mjs:53:30361)
at Object.getByTag (file:///var/task/frontend/index.mjs:53:31233)
at p.revalidateTag (/var/task/frontend/cache.cjs:2:4510)
at IncrementalCache.revalidateTag (/var/task/node_modules/next/dist/server/lib/incremental-cache/index.js:183:198)
at rC (/var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:15:3494)
at /var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:16:450
at async rT (/var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:15:8148) {
code: 'ERR_INVALID_ARG_TYPE'
}

this is my function


'use server';
import { v4 as uuidv4 } from 'uuid';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

export default async function getPresignedUrl() {

  const region = 'eu-central-1';
  const bucketName = process.env.ASSETS_BUCKET_NAME;

  if (!bucketName) {
    throw new Error('Bucket name is not defined in the environment variables.');
  }

  const s3Client = new S3Client({
    region: region,
  });

  const key = `_assets/uploads/${uuidv4()}`;

  const command = new PutObjectCommand({
    Bucket: bucketName,
    Key: key,
  });

  const url = await getSignedUrl(s3Client, command, { expiresIn: 3600 });

  const isLocal = process.env.NODE_ENV === 'development' || process.env.SST_STAGE === 'local';
  const fileUrl = isLocal
    ? `https://${bucketName}.s3.${region}.amazonaws.com/${key}`
    : `${process.env.NEXT_PUBLIC_CLOUDFRONT_URL}/${key.replace('_assets/', '')}`;

  return { url, key: fileUrl };
}


@ijjk ijjk closed this as completed in cdb78b4 Sep 30, 2024
ijjk pushed a commit to ijjk/next.js that referenced this issue Sep 30, 2024
…rcel#70446)

Fixes vercel#70403

### What?
When `revalidateTag()` is called directly in server components, the
cache is not purged for the corresponding tags. Reproduction steps
available in vercel#70403

### How?
Check
[app-render.tsx](https://github.com/vercel/next.js/compare/canary...abhi12299:fix-revalidatetag-rsc?expand=1#diff-a3e2e024db1faa1b501e0dd6040eaaf0d931cb9878ae0fb0f4c3658daa982768)
This issue was introduced in vercel#65296 in this file:
[revalidate.ts](https://github.com/vercel/next.js/pull/65296/files#diff-7f0cb5bb30d44b9153d724e31c25859b9aab6cc258b35563a1d9464cd0688283).
The lines removed from the file resulted in the revalidation checks to
be skipped when there is an RSC request.

Also fixed checks on `pendingRevalidates` to also check for
`revalidatedTags`.

---------

Co-authored-by: JJ Kasper <[email protected]>
# Conflicts:
#	packages/next/src/server/app-render/app-render.tsx
ijjk added a commit that referenced this issue Sep 30, 2024
…0446) (#70642)

This backports #70446 to 14-2-1

Fixes #70403

### What?
When `revalidateTag()` is called directly in server components, the
cache is not purged for the corresponding tags. Reproduction steps
available in #70403

### How?
Check

[app-render.tsx](https://github.com/vercel/next.js/compare/canary...abhi12299:fix-revalidatetag-rsc?expand=1#diff-a3e2e024db1faa1b501e0dd6040eaaf0d931cb9878ae0fb0f4c3658daa982768)
This issue was introduced in #65296 in this file:

[revalidate.ts](https://github.com/vercel/next.js/pull/65296/files#diff-7f0cb5bb30d44b9153d724e31c25859b9aab6cc258b35563a1d9464cd0688283).
The lines removed from the file resulted in the revalidation checks to
be skipped when there is an RSC request.

Also fixed checks on `pendingRevalidates` to also check for
`revalidatedTags`.

Co-authored-by: Abhishek Mehandiratta <[email protected]>
@markedwards
Copy link

markedwards commented Oct 5, 2024

@markedwards can you provide a reproduction repo?

I haven't narrowed it down yet, and the actual repro involves setting up a page with an EventStream, and building a stream. It's a bit too complicated. Will dig in to it further, but this issue caught my eye as potentially related.

As far as I can tell, cache revalidation is simply broken when called in a streaming callback in a route handler. I'll see if I can get a minimal repro and create an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue was opened via the bug report template.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants