search

opennextjs / opennextjs-aws

Open-source Next.js adapter for AWS
https://opennext.js.org
MIT License
4.14k stars 126 forks source link

fix: add more reliable sources to the revalidate e2e test #600

Closed sommeeeer closed 2 weeks ago

sommeeeer commented 2 weeks ago

This PR adds more reliable sources to the fetches in revalidateTag.test.ts e2e

changeset-bot[bot] commented 2 weeks ago

⚠️ No Changeset found

Latest commit: 3e13dc3e487af8bf26f5b927bb112243af1829c7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

sommeeeer commented 2 weeks ago

We're on next 15 now correct? If so, fetch by default doesn't cache, so I don't think this e2e would test for the revalidate since the amz-id would be unique on each request.

yeah we are on 15, forgot about the new beautiful cache behavior. however, you can see the behavior yourself too by pnpm build && pnpm start with this PR in app-router.

for some reason its working as it was next 14. maybe its something im missing thats completely obvious here. need to dig more into it

sommeeeer commented 2 weeks ago

alright, so this one was a bit confusing at first, but it must be related to the fact #L46-L54 made me think this route is not SSG.

since /revalidate-path is actually SSG, you can see that by looking at the x-nextjs-cache header being HIT and in the build log.

so each visit to /revalidate-path would still show the fetches as they were cached, but thats just because the page is static. triggering revalidatePath("/revalidate-path") would revalidate the entire page and thus also the fetches.

therefor we need to add export const dynamic = "force-dynamic" on top of this page and also force-cache on the fetches to get the caching-behavior we are aiming for.

this made me realize tho, should we maybe rework this a bit?

conico974 commented 2 weeks ago

therefor we need to add export const dynamic = "force-dynamic" on top of this page and also force-cache on the fetches to get the caching-behavior we are aiming for.

That's not the point of this test. We test that it revalidate the page not the fetch cache.

We may want to add a new e2e test to test the fetch cache behavior, but it's likely broken again in Next 15. We could just cache those fetch here and add other test. (I'm surprised that the codemod did not change that to use caching, seems weird)

sommeeeer commented 2 weeks ago

That's not the point of this test. We test that it revalidate the page not the fetch cache.

alright, so i guess i can just keep the code as it is for now, and in a future PR add another one for the fetch cache.