Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

SSG not storing to s3 for dynamic pages with fallback: true

See original GitHub issue

Hi people,

Describe the bug

Say, we have dynamic pages /test/[id].js with some getStaticPaths(...fallback: true) and getStaticProps(...). When we request a new id, it renders the html correctly after a loading but it does not store anything on s3.

So, SSG is not working here!

We suspect that it does not deal multi-regions correctly, but we actually don’t know. Please read what follows.

Actual behavior

Nothing is stored in s3 when fallback:true for pages /test/xxx not statistically generated at build time. But it does work in localhost.

Expected behavior

After a hit, subsequent requests just follow the RFC that is get from s3, hit, render.

Additional information

We tested this with the following in /test/[id].tsx

import { GetStaticPaths, GetStaticProps } from "next";
import Head from "next/head";
import { useRouter } from "next/router";
import { useRef } from "react";

export const getStaticPaths: GetStaticPaths = async () => {
  return {
    fallback: true,
    paths: [{ params: { id: "e2efdd70-177f-4bf8-907d-a953c702a304" } }],
  };
};

export const getStaticProps: GetStaticProps = async ({}: any) => {
  return {
    props: {
      id: "e2efdd70-177f-4bf8-907d-a953c702a304",
      upload: {
        title: "UNICEF Children, food and nutrition.",
      },
    },
  };
};

export default function Publication({ upload }: any) {
  const router = useRouter();

  if (router.isFallback) {
    return (
      <div>
        <h1>Loading&hellip;</h1>
      </div>
    );
  }

  const title = useRef((upload && upload.title) || "docduo");

  return (
    <Head>
      <title>{title.current}</title>
    </Head>
  );
}

The content of /static-pages/test/[id].html is the following:

The content of _next/static/QTXnzCYbWqOui3ql6FK75/_buildManifest.js:

The content of _next/static/QTXnzCYbWqOui3ql6FK75/_ssgManifest.js is:

When I test the results of this with the following url: https://e.docduo.fr/test/59407fcb-a848-4ab5-95f0-019f613ea0c1 I expect to have something store in s3 after the first hit… but in the s3 folder there is just: Sans titre-1

The lambda function (we only see one lambda, Default @ Lambda/Edge, no API) has the following permissions (we also test with administrator permissions, does not work). Capture d’écran 2020-11-14 à 22 41 44

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Resource": "*",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ]
        },
        {
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::1k4854-p0yvzbh/*",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ]
        }
    ]
}

Strangely, there is no lambda invocation (on us-east-1, where the plugin creates the lambda)

The serverless includes a domain where we issue a certificate in us-east-1

# serverless.yml
nextamplified:
  component: "@sls-next/serverless-component@1.19.0-alpha.7"
  inputs: 
    domain: ["e", "docduo.fr"]

Also maybe this is relevant, the cloudwatch logs are in ue-west-1: Capture d’écran 2020-11-14 à 22 29 20

But the plugin setups one lambda in us-east-1.

In cloudfront, under _next/data* we have this setup (automatically by the plugin, it looks nice) Capture d’écran 2020-11-14 à 22 51 21

Under s3, there is the following perms:

{
    "Version": "2012-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": " Grant a CloudFront Origin Identity access to support private content",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E376221HJ5Y29H"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::1k4854-p0yvzbh/*"
        }
    ]
}

Versions

OS/Environment: mac os, chrome
@sls-next/serverless-component version: 1.19.0-alpha.7
Next.js version: 10

Checklist

Issue Analytics

State:
Created 3 years ago
Comments:7

Top GitHub Comments

1reaction

dphangcommented, Nov 15, 2020

Thanks, looks like the problem is in here: https://github.com/serverless-nextjs/serverless-next.js/blob/84a3f40345c4e7a2e6dd72832ee148372bdcc813/packages/libs/lambda-at-edge/src/default-handler.ts#L361-L369. Instead of breaking to do SSR render of the data request in origin request handler for fallback data requests, we should try to return an s3 request to tell CloudFront fetch it from S3 (which will fail the first time, but the origin response handler will then fetch and store it in s3).

Not sure why it wasn’t caught in unit tests, I’ll fix it and update both the unit/e2e tests to catch this.

0reactions

danigrandemcommented, Feb 25, 2021

Im having the same problem. How can i solve this?

Thanks