Serverless-next.js: Dynamic route at pages level leds request for public resources to 503 Error

[gparonitti]

Describe the bug

When dynamic route is at pages level (e.g. pages/[lang]/index.jsx) public folder content return a 503 Error: "The Lambda function associated with the CloudFront distribution is invalid or doesn't have the required permissions. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation."

Actual behavior

When getStaticPaths is being used on a root level dynamic route (pages/[lang]/index.jsx), public folder or any not generated request that is issued at that level (www.example.com/foo), respond 503

Expected behavior

Public resources should be served correctly, and all the not generated request at root level should respond with a 404 page

Steps to reproduce

Put a dynamic route at root level /pages/[lang]/index.jsx with getStaticPaths and a public folder with favicon and the favicon is not reachable.

Versions

1.18.0-alpha.5

• @sls-next/serverless-component version: 1.18.0-alpha.5
• Next.js version: 9.5.5

Checklist

• [x] You have reviewed the README and FAQs, which answers several common questions.
• [x] Please first try using the latest @sls-next/serverless-component release version, which may have already fixed your issue. Note that the old serverless-next.js component and the serverless-next.js plugin are deprecated and no longer maintained.

[dphang]

May be related to this: https://github.com/serverless-nextjs/serverless-next.js/issues/646. I will take a look this week at both. Was making e2e tests more extensible so it's easier to add new ones, we will add tests for these cases so it shouldn't break in the future once fixed.

[gparonitti]

Yes most likely they are related. I add also this piece of information:

• if you try to reach https://www.example.com/foo --> 503. Wrong.
• if you try to reach https://www.example.com/foo/bar --> 404. Correct.

[dphang]

Should be fixed in https://www.npmjs.com/package/@sls-next/serverless-component/v/1.18.0-alpha.6

[gparonitti]

@dphang I just tried and folder public issue is solved. Unfortunately, the 503 issue which affects the first level of the pathname is not solved. If I request a dynamic route at first level of pages folder which has not been generated with getStaticPaths I receive 503 instead of 404. For example with /pages/[lang]/c where lang could be [en|it|fr]:

• https://www.example.com/foo --> 503. Wrong.
• https://www.example.com/foo/bar --> 404. Correct.

[dphang]

@gparonitti thanks for the update, what does CloudWatch log say for that 503? I don't think I could reproduce it. Are you using fallback: false? I think that is not supported yet, just fallback: true.

[gparonitti]

There are no log for 503 (I think it is delivered by Cloudfront). Yes the fallback is set to false I'll try true.

[dphang]

I think adding fallback: false I'll look into how to support it in another PR, should be just pointing S3 URI to the 404.html page

[dphang]

@gparonitti Hmm, strange, I thought there should still be CloudWatch log, if it mentions Lambda I think it should be in CloudWatch region closest to you

[dphang]

Anyway, I did repro with fallback: false, it gets a 503 because in Lambda, it is getting access denied from S3:

    "errorType": "AccessDenied",
    "errorMessage": "Access Denied",
    "Code": "AccessDenied",
    "RequestId": "10A4ADA9E37CB239",
    "HostId": "GlBEE7tbZ8Kpxr84Rn5GJV+ikrK0NUOk7hLre7gu8UV3eto4RHRx5Ba+OEGp8iXdZ+NIVmymkyY=",
    "name": "AccessDenied",
    "$fault": "client",
    "$metadata": {
        "httpStatusCode": 403,
        "httpHeaders": {
            "x-amz-request-id": "10A4ADA9E37CB239",
            "x-amz-id-2": "GlBEE7tbZ8Kpxr84Rn5GJV+ikrK0NUOk7hLre7gu8UV3eto4RHRx5Ba+OEGp8iXdZ+NIVmymkyY=",
            "content-type": "application/xml",
            "transfer-encoding": "chunked",
            "date": "Thu, 15 Oct 2020 08:00:15 GMT",
            "server": "AmazonS3"
        },
        "attempts": 1,
        "totalRetryDelay": 0
    },
    "stack": [
        "AccessDenied: Access Denied",
        "    at deserializeAws_restXmlGetObjectCommandError (/var/task/index.js:14734:41)",
        "    at processTicksAndRejections (internal/process/task_queues.js:97:5)"
    ]
}

This is happening because it's trying to retrieve a non-existent page first (getting a 403) and in origin response handler it doesn't have logic to retrieve 404 page, instead it just returns the response as is. We can probably fix to just retrieve the 404.html page in such case in origin request handler.

[dphang]

Supported 404 pages for fallback: false in 1.18.0-alpha.8. Please try and let me know if there are any issues.

[gparonitti]

Thank you for the awesome support!!! You're a rockstar 🥇 !