ISR(Incremental Static Regeneration) feature not generating dynamic pages in s3 bucket

[techexe-code]

pages are generated in s3 on this folder[static-pages/{**}.html and _next/data/{id}/*.json] build time only

when I open url like page/3 in my browser it's always show me loading state then comes up main content and this page is not being generated in s3

function Post({ post }) {
  const router = useRouter()
  if (router.isFallback) {
    return <div>Loading...</div>
  }

  // Render post...
}

// This function gets called at build time
export async function getStaticPaths() {
  return {
    // Only `/posts/1` and `/posts/2` are generated at build time
    paths: [{ params: { id: '1' } }, { params: { id: '2' } }],
    // Enable statically generating additional pages
    // For example: `/posts/3`
    fallback: true,
  }
}

// This also gets called at build time
export async function getStaticProps({ params }) {
  const res = await fetch(`https://.../posts/${params.id}`)
  const post = await res.json()

  return {
    props: { post },
    revalidate: 5,
  }
}

export default Post

[dphang]

We do have e2e test for fallback page here:

serverless-next.js/packages/e2e-tests/next-app-dynamic-routes/pages/optional-catch-all-ssg-with-fallback/[[...catch]].tsx

Line 38 in 2b9dfd8

{ params: { catch: ["b"] } }

/a and /b are generated at build time, rest are first with fallback page but then data request should generate and save the page/data in S3.

You can try here with some random route: https://d2aheyeo29vn1i.cloudfront.net/optional-catch-all-ssg-with-fallback/[random string], first time it will serve fallback page (which is never cached) and then 2nd time (if you hit the same route) it will serve that page

I am wondering if you are maybe caching the fallback page causing this behavior? What is your min cache TTL? If you set some min cache in CloudFront, it will force CloudFront to cache that irrespective of cache control header (for fallback it is public, max-age=0, s-maxage=0, must-revalidate so it should never be cached unless you have a min TTL on CloudFront)

[techexe-code]

Cache behaviour of CloudFront

path pattern : Default (*)
Minimum TTL : 0
Maximum TTL : 31536000
Default TTL : 0

path pattern : _next/data/*
Minimum TTL : 0
Maximum TTL : 31536000
Default TTL : 0

path pattern : _next/static/*
Minimum TTL : 0
Maximum TTL : 31536000
Default TTL : 86400

path pattern : static/*
Minimum TTL : 0
Maximum TTL : 31536000
Default TTL : 86400

[dphang]

Strange, then I am not quite sure what is going on..is there any other error in the console/network tab or perhaps some S3 write permission issue?

If you are able, please try to build this component and add logs around here:

serverless-next.js/packages/libs/lambda-at-edge/src/default-handler.ts

Lines 639 to 660 in 2b9dfd8

	const s3JsonParams = {
	Bucket: bucketName,
	Key: `${s3BasePath}${jsonKey}`,
	Body: JSON.stringify(renderOpts.pageData),
	ContentType: "application/json",
	CacheControl: "public, max-age=0, s-maxage=2678400, must-revalidate"
	};
	const s3HtmlParams = {
	Bucket: bucketName,
	Key: `${s3BasePath}${htmlKey}`,
	Body: html,
	ContentType: "text/html",
	CacheControl: "public, max-age=0, s-maxage=2678400, must-revalidate"
	};
	const { PutObjectCommand } = await import(
	"@aws-sdk/client-s3/commands/PutObjectCommand"
	);
	await Promise.all([
	s3.send(new PutObjectCommand(s3JsonParams)),
	s3.send(new PutObjectCommand(s3HtmlParams))
	]);
	}

, this is where it writes back the page/data to S3. Or if you are able to create a repro repository with similar settings as your project, it would great help too. Thanks!

[techexe-code]

not getting any error in console. I don't think there is s3 write permission issue because pages are getting stored during the deployment.

[dphang]

Yes, I was referring to if there is a runtime permission issue of Lambda itself (not AWS key used during deployment, that definitely should be fine)

[techexe-code]

Is there any way to debug this issue ?
Working fine in localhost

[techexe-code]

I have created new project and deployed it to CloudFront but still same issue

build time pages

https://d3vk8t6m4jw2vm.cloudfront.net/post/first
https://d3vk8t6m4jw2vm.cloudfront.net/post/second

above two pages are served from s3

  // This function gets called at build time
  export async function getStaticPaths() {
    return {
      // Only `/post/first` and `/post/second` are generated at build time
      paths: [{ params: { id:'first' } }, { params: {id:'second'} }],
      // Enable statically generating additional pages
      // For example: `/post/third`
      fallback: true,
    }
  }

  // This also gets called at build time
  export async function getStaticProps({ params }) {
    const post = {'id':params.id};
  
    await new Promise(res => setTimeout(res,3000))

    return {
      props: { post },
      revalidate: 5,
    }
  }
  

fallback pages
https://d3vk8t6m4jw2vm.cloudfront.net/post/third
https://d3vk8t6m4jw2vm.cloudfront.net/post/xxx

and these pages are not getting stored in s3 and loading on every request

[dphang]

I did check your link and your fallback page for some reason is being cached: cache-control: public, max-age=0, s-maxage=2678400, must-revalidate, which would be the cause of it always loading fallback page. However, it should not be per:

serverless-next.js/packages/libs/lambda-at-edge/src/default-handler.ts

Line 740 in f64fec4

? "public, max-age=0, s-maxage=0, must-revalidate" // fallback should never be cached

Are you using the latest alpha version? If so, I believe this might have been fixed. I forgot to check which version you were on, in the future please include that so we can verify if it was already fixed.

If you are still having the same issue on latest version, I am not sure what is going on, so either:

1. You will need to either debug this component yourself by adding log statements / etc. to the code I pointed (default handler) and build and deploy it.
2. If you can share a GitHub repo that can reproduce the issue on the latest alpha version, I can take a look at it.

[techexe-code]

No, I am using 1.18.0 version

@sls-next/serverless-component@1.18.0

[techexe-code]

Thanks again @dphang

I have changed version to @sls-next/serverless-component@1.19.0-alpha.45 and Yes, now page is being generated in s3 but has some problem with revalidation.

[techexe-code]

@sls-next/serverless-component@1.19.0-alpha.45

I am facing problem with the page revalidation feature of ISR.
I have declared x seconds for revalidation of page but page is still used old content and not getting updated.

This issue is with @sls-next/serverless-component@1.19.0-alpha.45 or from my side ?

[dphang]

It's not supported yet unfortunately... #804 I am working on releasing 1.19 this month and then hopefully we can take it up. Looks like there is a bounty too

[techexe-code]

Great, I really appreciate you and waiting for next release. 😊

[adamdotdevin]

Looks like there is a bounty too

There is! I'm offering a $2000 bounty for ISR support.