503 on SSG routes that should 404 when App uses getInitialProps

Me again! I’m getting a Cloudfront 503 response from routes that match SSG pages (fallback: false) where I expect to get 404s, only when I have a custom _app that has getInitialProps. I have created a reproduction here: https://github.com/patricktyndall/sls-next-bug-repro

More info

• I started seeing this issue after upgrading, as instructed by @dphang in #873. (I was able to access old pages, then I upgraded, then those became 503s, as did all other routes that should have 404’d).
• The repro has several “custom”-ish behaviors. These generally work fine and are supported, but could be related to the issue. These include: – a rewrite that maps all paths into a pages subdirectory (/content/) – a “no-op” rewrite
• This actually is a big SEO hazard because if you don’t have a robots.txt, it will 503, which google considers a “server error”.

Describe the bug

503 where I expect 404s

Screenshots/Code/Logs

Here’s what I see in Cloudfront. Does this mean anything to anyone?

ERROR	Invoke Error
{
    "errorType": "AccessDenied",
    "errorMessage": "Access Denied",
    "Code": "AccessDenied",
    "RequestId": "4384B55F0F8A5769",
    "HostId": "NMXCRIP/83sFgCtzWTAeov1m05xK919JJbPkOeF2J20XAVwG3lYDHLdrF3SRrv1MIBY0EZ7RlYs=",
    "name": "AccessDenied",
    "$fault": "client",
    "$metadata": {
        "httpStatusCode": 403,
        "httpHeaders": {
            "x-amz-request-id": "4384B55F0F8A5769",
            "x-amz-id-2": "NMXCRIP/83sFgCtzWTAeov1m05xK919JJbPkOeF2J20XAVwG3lYDHLdrF3SRrv1MIBY0EZ7RlYs=",
            "content-type": "application/xml",
            "transfer-encoding": "chunked",
            "date": "Mon, 01 Feb 2021 20:30:05 GMT",
            "server": "AmazonS3"
        },
        "attempts": 1,
        "totalRetryDelay": 0
    },
    "stack": [
        "AccessDenied: Access Denied",
        "    at deserializeAws_restXmlGetObjectCommandError (/var/task/index.js:19234:41)",
        "    at processTicksAndRejections (internal/process/task_queues.js:97:5)"
    ]
}

Versions

• OS/Environment: Amazon Linux
• @sls-next/serverless-component version: @sls-next/serverless-component@1.19.0-alpha.30
• Next.js version: ^10.0.6

[dphang]

Sorry just got back to this now, it was a bit hard to debug at first but I finally found it’s because the 404.html page is not generated by Next.js when adding the _app.js, the origin response handler is thus failing to find the s3 page (for fallback: false) and returns a 403 from s3 client -> in turn this is treated as an error in the Lambda, leading to a 503 page. I think you need to add a pages/404.js with getStaticProps as well to generate a static 404 HTML page at build time that’s uploaded to s3, so it returns the proper 404 instead. For example

export default function Custom404() {
    return <h1>404 - Page Not Found</h1>
}

export async function getStaticProps(){
    return {
        props: {
        }
    };
}

I’ll work on improving the logic so that we check whether a 404 page was actually generated by Next.js and we can just return an empty 404 page instead of trying to access a non-existent s3 key.

[patricktyndall]

Nope. My workaround: Every time I deploy I have to create a Cloudfront custom error response that replaces the 503 with a 404, so google indexes my site.

Are you using rewrites?